Electronic wallet apparatus, method, and computer program product

ABSTRACT

Registration information for a plurality of consumers is obtained at an electronic wallet platform. A mechanism is provided to integrate the electronic wallet platform with a plurality of merchants. Via the electronic wallet platform, a given one of the consumers is afforded an option to select from multiple methods to pay for a transaction with a given one of the merchants. The multiple methods are based, at least in part, on the registration information. At least one of the multiple methods includes a virtual card number. Further steps include obtaining, from the given one of the consumers, a selection of the virtual card number for payment for the transaction; and providing the given one of the merchants with the virtual card number.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a divisional of U.S. patent application Ser.No. 13/836,326, filed Mar. 15, 2013, entitled ELECTRONIC WALLETAPPARATUS, METHOD, AND COMPUTER PROGRAM PRODUCT, which in turn claimsthe benefit of U.S. Provisional Patent Application Ser. No. 61/722,294,filed Nov. 5, 2012, entitled ELECTRONIC WALLET APPARATUS, METHOD, ANDCOMPUTER PROGRAM PRODUCT. The complete disclosures of the aforementionedpatent application Ser. No. 13/836,326 and Provisional PatentApplication Ser. No. 61/722,294 are expressly incorporated herein byreference in their entireties for all purposes.

FIELD OF THE INVENTION

The present invention relates generally to electronic commerce, and,more particularly, to electronic payment systems.

BACKGROUND OF THE INVENTION

With the growth of Internet commerce, the electronic wallet (e-wallet),also known as a digital wallet, has been developed. An e-wallet providesconsumers with a secure and convenient way to pay for purchases fromaccepting on-line merchants. Upon registration, consumers may storetheir card, billing and shipping information on a site hosted by asuitable entity, and may access that information to pay conveniently andsecurely across participating merchants.

SUMMARY OF THE INVENTION

Principles of the present invention provide techniques for an electronicwallet apparatus, method, and computer program product. An exemplaryembodiment of a method, according to one aspect of the invention,includes obtaining, at an electronic wallet platform, registrationinformation for a plurality of consumers; providing a mechanism tointegrate the electronic wallet platform with a plurality of merchants;and, via the electronic wallet platform, affording a given one of theconsumers an option to select from multiple methods to pay for atransaction with a given one of the merchants. The multiple methods arebased, at least in part, on the registration information. At least oneof the multiple methods includes a virtual card number. Further stepsinclude obtaining, from the given one of the consumers, a selection ofthe virtual card number for payment for the transaction; and providingthe given one of the merchants with the virtual card number.

In another aspect, another exemplary method includes obtaining, at anelectronic wallet platform, registration information for a plurality ofconsumers; and making available to the consumers a secure applicationfor portable devices of the consumers which affords the consumers anoption to select from multiple methods to pay for transactions withmerchants. The multiple methods are based, at least in part, on theregistration information. At least one of the multiple methods includesa virtual card number. A further step includes intercepting anauthorization request, from a given one of the merchants, for an amountof a given one of the transactions to be charged against a given one ofthe virtual card numbers. The given one of the transactions includes agiven one of the consumers presenting a given one of the portabledevices, having the secure application thereon, at a point-of-saleterminal of the given one of the merchants. The virtual card number hadbeen provided to the merchant via communication between the given one ofthe portable devices and the point-of-sale terminal of the given one ofthe merchants. Further steps include translating the given one of thevirtual card numbers into an actual card number which is not provided tothe given one of the merchants; and passing the authorization request toan issuer, with the actual card number therein.

In a further aspect, another exemplary method includes obtaining, at anelectronic wallet server, product information in connection with anon-line shopping session of a consumer with an e-commerce retailer;dispatching, from the electronic wallet server, shipping optioninformation, destined for the consumer, providing at least two optionsfor shipping goods, associated with the product information, from thee-commerce retailer to the consumer; and obtaining, at the electronicwallet server, in connection with the on-line shopping session, anindication of a desired form of shipping from the e-commerce retailer tothe consumer, the indication being based on the shipping optioninformation.

In a still further aspect, another exemplary method includes obtaining,by an electronic wallet platform, transaction data pertaining to atransaction between a consumer and a merchant for provision of at leastone of goods and services. The electronic wallet platform has at leastfirst and second funding sources available. A further step includesdispatching, from the electronic wallet platform, based on thetransaction data, a first cost scenario for the transaction based on useof the first one of the funding sources and a second cost scenario forthe transaction based on use of the second one of the funding sources.The first and second cost scenarios are destined for the consumer.Further steps include obtaining, at the electronic wallet platform, fromthe consumer, a selection, from among the at least first and secondfunding sources, based on the first and second cost scenarios; andproviding the merchant an account number associated with the selectedfunding source.

In an even further aspect, another exemplary method includes obtaining,by an electronic wallet mobile application, transaction data pertainingto a transaction between a consumer and a merchant for provision of atleast one of goods and services. The electronic wallet mobileapplication has at least first and second funding sources available.Further steps include determining, by the electronic wallet mobileapplication, based on the transaction data, a first cost scenario forthe transaction based on use of the first one of the funding sources anda second cost scenario for the transaction based on use of the secondone of the funding sources; obtaining, at the electronic wallet mobileapplication, from the consumer, a selection, from among the at leastfirst and second funding sources, based on the first and second costscenarios; and providing the merchant an account number associated withthe selected funding source.

In yet a further aspect, an exemplary wallet platform server apparatusincludes a memory; and at least one processor, coupled to said memory.Said at least one processor is operative to: obtain registrationinformation for a plurality of consumers; integrate with a plurality ofmerchants; and afford a given one of said consumers an option to selectfrom multiple methods to pay for a transaction with a given one of saidmerchants. Said multiple methods are based, at least in part, on saidregistration information. At least one of said multiple methodscomprises a virtual card number. Said at least one processor isoperative to obtain, from said given one of said consumers, a selectionof said virtual card number for payment for said transaction; andprovide said given one of said merchants with said virtual card number.

Aspects of the invention contemplate the method(s) performed by one ormore entities herein, as well as facilitating of one or more methodsteps by the same or different entities. As used herein, “facilitating”an action includes performing the action, making the action easier,helping to carry the action out, or causing the action to be performed.Thus, by way of example and not limitation, instructions executing onone processor might facilitate an action carried out by instructionsexecuting on a remote processor, by sending appropriate data or commandsto cause or aid the action to be performed. For the avoidance of doubt,where an actor facilitates an action by other than performing theaction, the action is nevertheless performed by some entity orcombination of entities.

One or more embodiments of the invention or elements thereof can beimplemented in the form of a computer program product including atangible computer readable recordable storage medium with computerusable program code for performing the method steps indicated storedthereon in a non-transitory manner. Furthermore, one or more embodimentsof the invention or elements thereof can be implemented in the form of asystem (or apparatus) including a memory and at least one processor thatis coupled to the memory and operative to perform exemplary methodsteps. For example, the computer readable program code, when executed onone or more processors, cerates the platform 5497. Yet further, inanother aspect, one or more embodiments of the invention or elementsthereof can be implemented in the form of means for carrying out one ormore of the method steps described herein; the means can include (i)specialized hardware module(s), (ii) software module(s) stored in anon-transitory manner in a tangible computer-readable recordable storagemedium (or multiple such media) and implemented on a hardware processor,or (iii) a combination of (i) and (ii); any of (i)-(iii) implement thespecific techniques set forth herein. The means are defined to exclude atransmission medium per se or a disembodied signal per se.

One or more embodiments of the invention can provide substantialbeneficial technical effects, including, for example,

-   -   Creating a process flow wherein a pass-through is provided        between the merchant and logistics provider    -   Creating one or more shipping functions in a merchant account        that allow merchants to select their preferences    -   Creating a comparison function in a transaction flow that        permits comparison of the consumer's data with the merchant's        preferences    -   Allowing small or medium-sized merchants to more accurately        determine volumetric data regarding products to be shipped, to        thereby allow, for example, more accurate estimation of shipping        times and/or costs    -   Reducing time expended and/or likelihood of errors in        determining which payment vehicle offers the best terms for a        given transaction    -   Permit enhanced security of a virtual card number while allowing        consumer to obtain benefit of offers, discounts, and the like        linked to a real card number.

These and other features and advantages of the present invention willbecome apparent from the following detailed description of illustrativeembodiments thereof, which is to be read in connection with theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a general example of a payment system, which is anexemplary context within which one or more embodiments of the inventioncan be implemented;

FIG. 2 depicts an exemplary inter-relationship between and among: (i) apayment network configured to facilitate transactions between multipleissuers and multiple acquirers, (ii) a plurality of users, (iii) aplurality of merchants, (iv) a plurality of acquirers, and (v) aplurality of issuers;

FIG. 3 is a schematic representation of a mobile phone-basedpayment/authentication system in accordance with an aspect of theinvention;

FIG. 4 is a block diagram of a “smart” phone or tablet computerconfigured in accordance with an aspect of the invention; FIG. 5 is anexemplary software architecture diagram;

FIG. 6 is a flow chart showing an authentication system wherein featuresof a merchant plug-in (MPI) and an access control server (ACS) areincorporated into a wallet server;

FIG. 7 is an exemplary system block diagram;

FIG. 8 is a block diagram of an exemplary computer system useful in oneor more embodiments of the invention;

FIG. 9 depicts an exemplary transaction at an international merchantusing a pre-paid card;

FIG. 10 depicts an exemplary transaction at an international merchantusing a local funding card;

FIGS. 11-18 show exemplary screen shots for a payment process inaccordance with the prior art;

FIGS. 19-24 show exemplary screen shots for a payment process inaccordance with an aspect of the invention, wherein an electronic walletutilizes virtual card numbers;

FIG. 25 is a data flow diagram for the process of FIGS. 19-24;

FIGS. 26-31 show exemplary screen shots for a payment process inaccordance with the prior art;

FIGS. 32-39 show exemplary screen shots for a payment process inaccordance with an aspect of the invention, wherein an electronic walletutilizes virtual card numbers;

FIGS. 40-46 show exemplary screen shots for cross-border online shoppingin accordance with the prior art;

FIGS. 47-51 show exemplary screen shots for cross-border online shoppingin accordance with an aspect of the invention;

FIG. 52 is a flow chart comparing the processes if FIGS. 40-46 and47-51;

FIG. 53 is a data flow diagram for the process of FIGS. 47-51; and

FIG. 54 is another exemplary software architecture diagram.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Attention should now be given to FIG. 1, which depicts an exemplaryembodiment of a system 100, according to an aspect of the invention, andincluding various possible components of the system. In this regard, oneor more embodiments of the invention involve the operator of a paymentnetwork; e.g., an entity such as MasterCard International Incorporated,operator of the BANKNET® network, or Visa International ServiceAssociation, operator of the VISANET® network. This should be kept inmind in connection with the description of FIGS. 1 and 2. It should benoted that some aspects of the invention are directed tocard-not-present Internet commerce, while other embodiments of theinvention involve presentation (for example, via near-fieldcommunications (NFC)) of a payment device, such as an appropriatelyconfigured “smart” cellular phone, at a point of sale terminal of amerchant.

System 100 can include one or more different types of portable paymentdevices. For example, one such device can be a contact device such ascard 102. Card 102 can include an integrated circuit (IC) chip 104having a processor portion 106 and a memory portion 108. A plurality ofelectrical contacts 110 can be provided for communication purposes. Inaddition to or instead of card 102, system 100 can also be designed towork with a contactless device such as card 112. Card 112 can include anIC chip 114 having a processor portion 116 and a memory portion 118. Anantenna 120 can be provided for contactless communication, such as, forexample, using radio frequency (RF) electromagnetic waves. An oscillatoror oscillators, and/or additional appropriate circuitry for one or moreof modulation, demodulation, downconversion, and the like can beprovided. Note that cards 102, 112 are exemplary of a variety of devicesthat can be employed. The system per se may function with other types ofdevices in lieu of or in addition to “smart” or “chip” cards 102, 112;for example, a conventional card 150 having a magnetic stripe 152.Furthermore, an appropriately configured cellular telephone handset,personal digital assistant (PDA), and the like can be used to carry outcontactless payments in some instances.

The ICs 104, 114 can contain processing units 106, 116 and memory units108, 118. Preferably, the ICs 104, 114 can also include one or more ofcontrol logic, a timer, and input/output ports. Such elements are wellknown in the IC art and are not separately illustrated. One or both ofthe ICs 104, 114 can also include a co-processor, again, well-known andnot separately illustrated. The control logic can provide, inconjunction with processing units 106, 116, the control necessary tohandle communications between memory unit 108, 118 and the input/outputports. The timer can provide a timing reference signal from processingunits 106, 116 and the control logic. The co-processor could provide theability to perform complex computations in real time, such as thoserequired by cryptographic algorithms.

The memory portions or units 108, 118 may include different types ofmemory, such as volatile and non-volatile memory and read-only andprogrammable memory. The memory units can store transaction card datasuch as, e.g., a user's primary account number (“PAN”) and/or personalidentification number (“PIN”). The memory portions or units 108, 118 canstore the operating system of the cards 102, 112. The operating systemloads and executes applications and provides file management or otherbasic card services to the applications. One operating system that canbe used is the MULTOS® operating system licensed by MAOSCO Limited.(MAOSCO Limited, St. Andrews House, The Links, Kelvin Close, Birchwood,Warrington, WA3 7PB, United Kingdom) Alternatively, JAVA CARD™-basedoperating systems, based on JAVA CARD™ technology (licensed by SunMicrosystems, Inc., 4150 Network Circle, Santa Clara, Calif. 95054 USA),or proprietary operating systems available from a number of vendors,could be employed. Preferably, the operating system is stored inread-only memory (“ROM”) within memory portion 108, 118. In an alternateapproach, flash memory or other non-volatile and/or volatile types ofmemory may also be used in the memory units 108, 118.

In addition to the basic services provided by the operating system,memory portions 108, 118 may also include one or more applications. Atpresent, one possible specification to which such applications mayconform is the EMV interoperable payments specification set forth byEMVCo, LLC (901 Metro Center Boulevard, Mailstop M3-3D, Foster City,Calif., 94404, USA). It will be appreciated that applications can beconfigured in a variety of different ways.

As noted, cards 102, 112 are examples of a variety of payment devicesthat can be employed. The primary function of the payment devices maynot be payment, for example, they may be cellular phone handsets thatimplement aspects of the invention. Such devices could include cardshaving a conventional form factor, smaller or larger cards, cards ofdifferent shape, key fobs, personal digital assistants (PDAs),appropriately configured cell phone handsets, or indeed any device withthe capabilities to implement aspects of the invention. In some cases,the cards, or other payment devices, can include body portions (e.g.,laminated plastic layers of a payment card, case or cabinet of a PDA orcellular phone, chip packaging, and the like), memories 108, 118associated with the body portions, and processors 106, 116 associatedwith the body portions and coupled to the memories. The memories 108,118 can contain appropriate applications. The processors 106, 116 can beoperative to facilitate execution of one or more method steps. Theapplications can be, for example, application identifiers (AIDs) linkedto software code in the form of firmware plus data in a card memory suchas an electrically erasable programmable read-only memory (EEPROM).

A number of different types of terminals can be employed with system100. Such terminals can include a contact terminal 122 configured tointerface with contact-type device 102, a wireless terminal 124configured to interface with wireless device 112, a magnetic stripeterminal 125 configured to interface with a magnetic stripe device 150,or a combined terminal 126. Combined terminal 126 is designed tointerface with any type of device 102, 112, 150. Some terminals can becontact terminals with plug-in contactless readers. Combined terminal126 can include a memory 128, a processor portion 130, a reader module132, and optionally an item interface module such as a bar code scanner134 and/or a radio frequency identification (RFID) tag reader 136. Items128, 132, 134, 136 can be coupled to the processor 130. Note that theprinciples of construction of terminal 126 are applicable to other typesof terminals and are described in detail for illustrative purposes.Reader module 132 can, in general, be configured for contactcommunication with card or device 102, contactless communication withcard or device 112, reading of magnetic stripe 152, or a combination ofany two or more of the foregoing (different types of readers can beprovided to interact with different types of cards e.g., contacted,magnetic stripe, or contactless). Terminals 122, 124, 125, 126 can beconnected to one or more processing centers 140, 142, 144 via a computernetwork 138. Network 138 could include, for example, the Internet, or aproprietary network (e.g., a virtual private network (VPN) such as isdescribed with respect to FIG. 2 below). More than one network could beemployed to connect different elements of the system. For example, alocal area network (LAN) could connect a terminal to a local server orother computer at a retail establishment. A payment network couldconnect acquirers and issuers. Further details regarding one specificform of payment network will be provided below. Processing centers 140,142, 144 can include, for example, a host computer of an issuer of apayment device.

Many different retail or other establishments, represented bypoints-of-sale 146, 148, can be connected to network 138. Differenttypes of portable payment devices, terminals, or other elements orcomponents can combine or “mix and match” one or more features depictedon the exemplary devices in FIG. 1. Again, some aspects of the inventionare directed to card-not-present Internet commerce, while otherembodiments of the invention involve presentation (for example, vianear-field communications (NFC)) of a payment device, such as anappropriately configured “smart” cellular phone, at a point of saleterminal of a merchant.

Portable payment devices can facilitate transactions by a user with aterminal, such as 122, 124, 125, 126, of a system such as system 100.Such a device can include a processor, for example, the processing units106, 116 discussed above. The device can also include a memory, such asmemory portions 108, 118 discussed above, that is coupled to theprocessor. Further, the device can include a communications module thatis coupled to the processor and configured to interface with a terminalsuch as one of the terminals 122, 124, 125, 126. The communicationsmodule can include, for example, the contacts 110 or antennas 120together with appropriate circuitry (such as the aforementionedoscillator or oscillators and related circuitry) that permitsinterfacing with the terminals via contact or wireless communication.The processor of the apparatus can be operable to perform one or moresteps described herein. The processor can perform such operations viahardware techniques, and/or under the influence of program instructions,such as an application, stored in one of the memory units.

The portable device can include a body portion. For example, this couldbe a laminated plastic body (as discussed above) in the case of “smart”or “chip” cards 102, 112, or the handset chassis and body in the case ofa cellular telephone.

It will be appreciated that the terminals 122, 124, 125, 126 areexamples of terminal apparatuses for interacting with a payment deviceof a holder. The apparatus can include a processor such as processor130, a memory such as memory 128 that is coupled to the processor, and acommunications module such as 132 that is coupled to the processor andconfigured to interface with the portable apparatuses 102, 112, 1420(discussed below). The processor 130 can be operable to communicate withportable payment devices of a user via the communications module 132.The terminal apparatuses can function via hardware techniques inprocessor 130, or by program instructions stored in memory 128. Suchlogic could optionally be provided from a central location such asprocessing center 140 over network 138. The aforementioned bar codescanner 134 and/or RFID tag reader 136 can be provided, and can becoupled to the processor, to gather attribute data, such as a productidentification, from a UPC code or RFID tag on a product to bepurchased.

The above-described devices 102, 112 can be ISO 7816-compliant contactcards or devices or NFC (Near Field Communications) or ISO14443-compliant proximity cards or devices. In operation, card 112 canbe touched or tapped on the terminal 124 or 128 (or an associatedreader), which then contactlessly transmits the electronic data to theproximity IC chip in the card 112 or other wireless device.

One or more of the processing centers 140, 142, 144 can include adatabase such as a data warehouse 154.

A dual-interface device 1302 is sometimes employed. Device 1302 is shownlarger than devices 102, 112 for illustrative convenience but can have asimilar form factor. Device 1302 includes an IC chip 1304 having aprocessor portion 1306 and a memory portion 1308. A plurality ofelectrical contacts 1310, similar to contacts 110, can be provided, aswell as an antenna 1320 similar to antenna 120, together with anoscillator or oscillators, and/or additional appropriate circuitry forone or more of modulation, demodulation, downconversion, and the like,as described with regard to device 112. Appropriate firmware to managethe two available interfaces can be provided, with operation otherwisebeing similar to devices 102, 112.

An appropriately configured cellular telephone handset 1420 can also beemployed in a number of embodiments. Handset 1420 is depicted insemi-schematic form in FIG. 1, and can include one or more IC chips suchas chip 1440 including a processing unit 1460 and a memory unit 1480.Wireless communication with a terminal can be provided via antenna 1500or with a second antenna 1800 similar to above-described antenna 120(i.e., the handset could have a second antenna for the paymentapplication). Note that antenna 1800 is depicted schematically, butcould be, e.g., a coil antenna as used in a typical “smart” card.Handsets 1420 can each be equipped with a suitable display 1560.Further, an appropriate power supply 1620 can also be provided. Suchpower supplies can include, for example, a battery and appropriatecircuitry. The display and power supply can be interconnected with theprocessor portion. Different types of portable payment devices cancombine or “mix and match” one or more features depicted on theexemplary devices in FIG. 1. Keypad 1680 and speaker 1740 can beprovided. Many current devices omit keypad 1680 and employ a touchscreeninstead; a more modern device of this type is shown in FIG. 4.

The description of devices, elements, or components 102, 104, 106, 108,110, 112, 114, 116, 118, 120 throughout this document are equallyapplicable to the corresponding items in the dual interface card 1302and cellular telephone handsets 10, 1420.

With reference to FIG. 2, an exemplary relationship among multipleentities is depicted. A number of different users (e.g., consumers)2002, U₁, U₂ . . . U_(N), interact with a number of different merchants2004, P₁, P₂ . . . P_(M). Merchants 2004 interact with a number ofdifferent acquirers 2006, A₁, A₂ . . . A_(I). Acquirers 2006 interactwith a number of different issuers 2010, I₁, I₂ . . . I_(J), through,for example, a single operator 2008 of a payment network configured tofacilitate transactions between multiple issuers and multiple acquirers;for example, MasterCard International Incorporated, operator of theaforementioned BANKNET® network, or Visa International ServiceAssociation, operator of the aforementioned VISANET® network. Ingeneral, N, M, I, and J are integers that can be equal or not equal.

In some cases, network 2008 uses ISO 8583 messaging. ISO 8583, Financialtransaction card originated messages—Interchange message specifications,is the International Organization for Standardization standard forsystems that exchange electronic transactions made by cardholders usingpayment cards. It has three parts: Part 1: Messages, data elements andcode values; Part 2: Application and registration procedures forInstitution Identification Codes (IIC); and Part 3: Maintenanceprocedures for messages, data elements and code values, all of which areexpressly incorporated herein by reference in their entirety for allpurposes. The skilled artisan in the payments processing field will bethoroughly familiar with ISO 8583 in any case.

During a conventional credit authorization process, the cardholder 2002pays for the purchase and the merchant 2004 submits the transaction tothe acquirer (acquiring bank) 2006. The acquirer verifies the cardnumber, the transaction type and the amount with the issuer 2010 andreserves that amount of the cardholder's credit limit for the merchant.At this point, the authorization request and response have beenexchanged, typically in real time. Authorized transactions are stored in“batches,” which are sent to the acquirer 2006. During subsequentclearing and settlement, the acquirer sends the batch transactionsthrough the credit card association, which debits the issuers 2010 forpayment and credits the acquirer 2006. Once the acquirer 2006 has beenpaid, the acquirer 2006 pays the merchant 2004.

It will be appreciated that the network 2008 shown in FIG. 2 is anexample of a payment network configured to facilitate transactionsbetween multiple issuers and multiple acquirers, which may be thought ofas an “open” system. A wide variety of other types of payment networkscan be used. For example, in some instances, a payment networkconfigured to facilitate transactions between multiple issuers and asingle acquirer could be used. Some embodiments of the invention may beemployed with other kinds of payment networks, for example, proprietaryor closed payments networks with only a single issuer and acquirer; withmobile networks; and/or with various types of electronic wallet servicesin conjunction with a suitable payment network. Furthermore, one or moreembodiments employ payment gateways, payment service providers, and/orpayment facilitators.

As seen in FIG. 2, in some instances, the owner or user of a smart phone10, 1420 or similar device configured in accordance with one or moreembodiments of the invention accesses a web site or the like of thepayment network operator 2008 to download a suitable wallet application12 (see FIG. 4) to the phone 10, 1420 or similar device. This feature isoptional. Note that the connection between phone 10, 1420 and paymentnetwork operator 2008 may very well be indirect; for example, paymentnetwork operator 2008 may provide a “golden copy” of the application 12to a third party and phone 10, 1420 downloads over the web from suchthird party. The link shown between phone 10, 1420 and payment networkoperator 2008 also represents the flow of data between phone 10, 1420and payment network operator 2008, and may be direct or indirect; forexample, via a cellular network and possibly with one or moreintermediate parties.

Referring now to FIG. 3, a mobile phone 10 can be associated with apayment card, e.g., a credit card, debit card or prepaid card. Themobile phone is preferably capable of storing and/or running a walletapplication 12, which is preferably a browser-based mobile applicationcapable of storing selected information such as a cardholder name, cardalias, billing/shipping address, etc., locally on the phone or in acloud server. In one preferred embodiment, the mobile phone is a “smartphone”, and the wallet application is stored in a memory device locatedin the phone. The arrangement of FIG. 3 enable payments across multiplechannels of commerce, e.g., a POS payment 14 by, for example, a PayPass®terminal (registered mark of MasterCard International Incorporated,Purchase, N.Y., USA), a remote mobile payment 16 initiated by a mobilephone, and/or a web-based payment 18.

As further described in FIG. 3, some embodiments use variousauthentication tools including an offline PIN 20, a SecureCode PIN 22,and/or an online PIN 24. It will be recognized that the foregoingmentioned PINs are currently in use in the marketplace and, accordingly,the use of such already existing PINs can facilitate the implementationof the present system. Of course, it is contemplated herein that a newindependent PIN (apart from the mentioned PINs) can be createdspecifically for use with one or more embodiments.

Offline PIN 20 preferably utilizes an offline personal identificationnumber (PIN) verification process whereby the PIN entered by theconsumer is verified by a secure element located on phone 10. In thisprocess, the wallet plays the role of a “virtual terminal,” interactingwith the secure element, and upon verification of the PIN, passes theCHIP token (Authorization Request Cryptogram or ARQC) to the merchantfor authorization. In this “virtual terminal”, the secure element servesthe role as the “card.” Offline PIN 20 can, for example, be used inconnection with a PayPass® payment. The skilled artisan will be familiarwith the terminology used in the description of FIG. 3 from theaforementioned EMV interoperable payments specification. Versions 4.0through 4.3 of the EMV Specifications, including Book 1, Book 2, Book 3,Book 4; version 1 of the EMV Common Payment Application Specification(CPA) plus bulletins; and version 1.1 of the EMV Card PersonalizationSpecification plus bulletins, are all expressly incorporated herein byreference in their entireties for all purposes. MasterCard PayPass® is anon-limiting example of an EMV compatible, “contactless” payment featurebased on the ISO/IEC 14443 standard that provides cardholders with asimpler way to pay by tapping a payment card or other payment device,such as a phone or key fob, on a point-of-sale terminal reader ratherthan swiping or inserting a card.

Secure Code PIN 22 is a PIN associated with a card enrolled in theMasterCard SecureCode® system (registered mark of MasterCardInternational Incorporated, Purchase, N.Y., USA). It is contemplatedherein that the SecureCode system could also utilize a password and/orcode, rather than a PIN.

Online PIN 24 is used in an online PIN verification process whereby thewallet application 12 plays the role of a “virtual terminal,”interacting to encrypt the PIN for transmission to the merchant. The useof an online PIN verification process may provide greater flexibility inauthenticating transactions by, for example, allowing an issuing bank toauthenticate the transactions associated with its cardholders withoutthe need for the issuing bank to enroll/register its cardholders and/oradopt new infrastructure.

Users may have different instances of wallet application 12 on differentphones. A sync service can maintain the various instances synchronizedwith an online server (similar to how browser bookmarks can be storedoffline in different instances of an internet browser and can besynchronized between various machines.) Merchants can add a piece ofcode to their checkout button that invokes the wallet application.During checkout, users select card and shipping address (if needed). Theauthentication PIN is entered into the phone in response to a promptfrom the mobile application. The wallet passes back the information tothe merchant who submits this information through existing channels(internet gateway or payment processor), i.e., no changes are requiredto existing processes or integration.

In a non-limiting example, the wallet application may be a browser HTML5 application (not a native application) that self-installs in themobile phone or computer browser on the first use. In a non-limitingexample, the wallet application is downloaded to the smart phone or thelike from an “app store” or the like on a server.

In another aspect, the wallet application can securely store informationon the phone (shipping address, card alias, secure token if used,virtual and/or real card number(s), etc.). This information can be usedfor a number of purposes; in some cases, to authenticate to the remoteserver. This also enables offline transactions. The mobile applicationcan preferably “talk” to the secure element on the phone (which may beon the subscriber identity module (SIM card) of the phone, for example).In this regard, the mobile application could play the role of a virtualPOS terminal in initiating card present CHIP plus PIN transactions. Onthe other hand, in some cases, the smart phone or the like is only usedas an actual payment device at a POS.

In some instances, a consumer may use his or her phone or computer toshop at a web-based retailer. When the consumer is ready to check out,he or she will preferably have the option of clicking a checkout buttonassociated with some aspects of the present system. Clicking the buttonprompts the consumer to provide his or her username and password tolog-in, and to confirm both the payment card to be used and the shippingaddress to which the item is to be sent. Thereafter, the system willprompt the consumer to enter the authenticating PIN, and the transactionis then completed. At that point, the consumer is preferably returned tothe merchant's site. This is a non-limiting example. Some embodimentsare directed to card-not-present Internet commerce with one or morevirtual card numbers in an electronic wallet on a server, and someembodiments are directed to a downloadable electronic wallet applicationon a smart phone or the like for use in transactions with the smartphone at brick and mortar retailers.

One or more embodiments provide one or more benefits to the consumer.Some embodiments provide easy and convenient checkout through a formfill or pass through function, which is preferably part of the walletapplication 12. Some embodiments provide secure payments via a PIN, orother biometric parameters such as a voice print or fingerprint. In thisregard, the smart phone may be provided with a biometric reader and/oranalyzer. Some embodiments omit one, some, or all of these features.

One or more embodiments provide one or more benefits to the merchant.Some embodiments include a potential liability shift from the merchantto the authorizing bank for all wallet-based transactions. Moreparticularly, the use of an authentication process for remotetransactions reduces the risk of fraud associated with suchtransactions, and may limit and/or reverse the shifting of fraudliability from the authorizing bank to the merchant. The use of theauthentication process may also provide more attractive economics to themerchant through access to lower fee structures, depending on theconsumer authentication method. One or more embodiments also providelimited integration impact in that a simple wallet application programinterface (API) is provided to pass card details, shipping informationand security tokens, and does not require any new contractualrelationships (i.e., existing card acceptance is leveraged). One or moreembodiments are backwards compatible, (i.e., native support is providedfor SecureCode® technology) thus resulting in better consumer experienceand/or ergonomics. Again, these details are exemplary, optional, andnon-limiting; some embodiments are directed to card-not-present Internetcommerce with one or more virtual card numbers in an electronic walleton a server, and some embodiments are directed to a downloadableelectronic wallet application on a smart phone or the like for use intransactions with the smart phone at brick and mortar retailers.

The wallet application 12 as described with respect to FIG. 3 provides acomprehensive solution to financial transactions conducted acrossmultiple channels of commerce. The wallet application 12 provides asimple and winning proposition to consumers, and in some instancesprovides a form fill option. One or more embodiments can use existingpayment networks 2008 and the like which are already accepted bymerchants, thereby eliminating the need for heavy integration, whileproviding more security and better economics. One or more embodiments donot require issuing banks to implement new requirements since they canfunction with existing authorization techniques, e.g., SecureCode®technology, CHIP and PIN and/or online PIN. Some embodiments contemplatethe long term convergence path of the three commerce platforms—retail,e-commerce and mobile—towards a mobile phone centric system. Otherembodiments, as noted, involve a server-based wallet, and optionally adownloadable wallet application, and may omit some or all of theenhanced authorization features described herein.

Some aspects can be employed in applications where the consumer owns a“dumb phone.” For example, in applications where the consumer isconducting an e-commerce transaction through his or her computer, or hasinitiated a call to a call center, and the consumer does not own a smartphone, the system in FIG. 3 can utilize existing SMS messaging or othermessaging technology to contact the “dumb phone” of the consumer andrequest the entry of a PIN. Upon receipt of the PIN from the “dumbphone”, the transaction can be authenticated and completed. This featureis entirely optional and may be omitted in one or more embodiments.

FIG. 4 is a block diagram of an exemplary tablet computing device orsmart phone 10 or the like. Unit 10 includes a suitable processor; e.g.,a microprocessor 402. A cellular transceiver module 404 coupled toprocessor 402 includes an antenna and appropriate circuitry to send andreceive cellular telephone signals, e.g., 3G or 4G. A WiFi transceivermodule 406 coupled to processor 402 includes an antenna and appropriatecircuitry to allow unit 400 to connect to the Internet via a wirelessnetwork access point or hotspot. The skilled artisan will appreciatethat “Wi-Fi” is a trademark of the Wi-Fi Alliance and the brand name forproducts using the IEEE 802.11 family of standards.

One or more embodiments include a wallet application 12 in memory 412which when executed causes the processor 402 to implement at least aportion of the functionality described herein. Operating system 427orchestrates the operation of unit 400. Apple's iOS is a non-limitingexample of a suitable operating system; other non-limiting examplesinclude Linux-based systems (registered mark of Linus Torvalds), WindowsPhone (registered mark of Microsoft Corporation), and the like.

Touch screen 410 coupled to processor 402 is also generally indicativeof a variety of input/output (I/O) devices such as a keypad, anothertype of display, a mouse or other pointing device, and so on, all ofwhich may or may not be present in one or more embodiments. Audio module418 coupled to processor 402 includes, for example, an audiocoder/decoder (codec), speaker, headphone jack, microphone, and so on.Power management system 416 can include a battery charger, an interfaceto a battery, and so on. Memory 412 is coupled to processor 402. Memory412 can include, for example, volatile memory such as RAM, andnon-volatile memory such as ROM, flash, or any tangiblecomputer-readable recordable storage medium which stores information ina non-transitory manner. Processor 402 will typically also have on-chipmemory.

Offers 5994 are discussed below.

Thus, some embodiments may be implemented, for example, at least in partvia an application that runs on a tablet or smart phone or the like andanother application that runs on a remote server or the like.

FIG. 5 shows an exemplary software architecture diagram. Wallet platform597 includes executable code, stored in a non-transitory manner in atangible computer-readable recordable storage medium, which, when loadedinto the memory of one or more servers, causes one or more processorsthereof to implement at least portions of the logic described herein.Database 1479 includes a suitable database program such as the OracleDBMS, Access and SQL Server from Microsoft, DB2 from IBM and the Opensource DBMS MySQL, stored in a non-transitory manner in a tangiblecomputer-readable recordable storage medium, as well as persistentstorage to store the records therein. The database program, when loadedinto the memory of one or more servers, causes one or more processorsthereof to implement the database(s) described herein (e.g., withpre-registration information). The various interface modules includeexecutable code, stored in a non-transitory manner in a tangiblecomputer-readable recordable storage medium, which, when loaded into thememory of one or more servers, causes one or more processors thereof toimplement the interface functionality and communication flows describedherein, included any needed data translation between the wallet platformand the external entities. GUI 1477 provides an interface to consumer598; shipping merchant interface module 1475 provides an interface toshipping merchant 599; balance inquiry service interface module 1469provides an interface to balance inquiry service 989; prepaid cardissuer interface module 1471 provides an interface to prepaid cardissuer 596; and e-commerce retailer interface module 1473 provides aninterface to e-commerce retailer 895. Furthermore, registration andaccount maintenance module 1483 interfaces with consumer 598 via GUI1477 to perform registration and maintenance functions; new data and/orupdates can be stored in database 1479. In some instances, local PANscome from prepaid card issuer 596 via interface 1471; module 1481determines what countries to obtain PANs for in accordance with thepertinent rule(s).

Referring to FIG. 6, in some embodiments, the wallet 1989 detectscheckout at the merchant 1999 at step 1901. The wallet 1989 thenauthenticates the user (step 1902), and payment details are selected(step 1902). The wallet server 1988 then determines that the bank is thewallet ACS (the bank's SecureCode® authentication server) customer, andthat no further authentication is necessary (step 1903). Next, thewallet form fills the payment details, including the AAV (AccountholderAuthentication Value), in the merchant page 1999. The merchant thenauthorizes the transaction in normal fashion (auth request with AAV tomerchant acquirer 990). This is passed through payment network 987 tobank authorization system 2010. Merchant acquirer 990 receives thenecessary approval (auth response) from system 2010 via network 987, andpasses same back to page 1999. In some instances, network 987 is anetwork such as network 2008. System 2010 is typically run by or onbehalf of the issuer, and thus has received the same reference characteras the issuer 2010 in FIG. 2.

FIG. 7 pertains to aspects of consumer offers. There are two differentways for a consumer to be enrolled in consumer enrollment database 1996.As at 1995, auto-enrollment is possible, based, for example, on accountsthat payment network operator (PNO) 2008 maintains; certain accounts maybe segmented and enabled for participation. As at 1994, in anotheraspect, the consumer may be given the opportunity to opt in. This couldbe carried out, for example, by having PNO 2008 or some other entitycarry out an analysis or check some other consumer database, toundertake an outreach, inviting one or more consumers to opt in. Thiscould be selective (targeted) or open. In any event, privacy of theconsumer should be respected such that some action should be required onthe part of the consumer (registration, confirmation, or the like)before the consumer shares any information or receives any offers. Inmany cases, this can be carried out on-line or via mobile messaging, orusing a clickable link in an e-mail. The consumer enrollment database1996 manages all the registered consumers. It ultimately maps back to ane-wallet account; e.g., via credit or debit card account or through thewallet account itself.

Offers registry 1997 typically involves business-to-businessinteraction. The rules of the offer are determined by whoever providesthe offer, whether a merchant, manufacturer, issuing bank, and so on.The appropriate entity provides the rules of the offer, the merchants atwhich the rules apply, a code range or some kind of identificationscheme for the offer, and so on. A single identifier could be used foreveryone to receive the offer; serialized identifiers could be provided,and so on. This information is stored in the offers registry 1997.

Transaction qualification service 1998 applies the rules in real time,based on registry 1997 and database 1996. Service 1998 applies the rulesof the registered offer to transaction information coming through forthe given consumer and determines if all the pieces are in place toqualify. Service 1998 then updates that particular consumer'sregistration and transaction records.

E-wallet platform 597 provides the interaction between the merchant andthe consumer 2002 as to the transaction that is to be qualified.Consumer 2002 goes to merchant checkout page 1999 and when the consumerindicates that he or she wishes to pay with the e-wallet, he or she isre-routed to the e-wallet platform 597 and pertinent transactioninformation provided by the merchant is then run through the transactionqualification service 1998. If a promotion is applicable, thisinformation is passed back to e-wallet platform 597, and when theconsumer completes interaction with e-wallet platform 597, thatinformation passes back to the merchant, as part of the interfacebetween e-wallet platform 597 and the merchant. If the merchant wants toaccept e-wallet platform 597, there will be certain messages themerchant will pass to e-wallet platform 597 and certain messages themerchant will receive back from e-wallet platform 597.

FIG. 9 depicts an exemplary transaction at an international merchantusing an existing pre-paid card. At 901, the consumer 598 respondsaffirmatively to an inquiry on whether to proceed with checkout afterbeing provided with fully landed costs. At 902, the e-commerce retailer895 generates a call to the e-wallet 597 to retrieve payment method andconfirm shipping address information. At 903, the e-wallet initiates arequest to the balance inquiry service 989 to generate a balance inquiryto the prepaid card issuer 596 to determine the amount of fundsremaining on the prepaid card. The e-wallet 597 provides the balanceinquiry service 989 with the prepaid PAN associated with the e-commerceretailer country.

At 904, the balance inquiry service formats and sends a balance inquiryauthorization request to the authorization network 987 (for example,network 2008) that is destined for the prepaid card issuer 596. At 905,the authorization network forwards the balance inquiry to the prepaidcard issuer. At 906, the prepaid card issuer sends an authorizationresponse for the balance inquiry with the amount of funds remaining onthe prepaid card to the authorization network. At 907, the authorizationnetwork sends the authorization response to the balance inquiry service.At 908, the balance inquiry service provides the balance information tothe e-wallet. At 909, the e-wallet generates a request to the fundingpurchase/payment transaction acquirer/processor 9999 to initiate apurchase against the default funding card associated with the consumer'sprofile for the amount that is the difference between the e-commercepurchase amount and the available amount on the prepaid card. E-wallet597 provides the entity 9999 with the funding card PAN information andthe amount.

Note that “0100” and “0110” refer to ISO 8583 messages “authorizationrequest” and “authorization request response.”

At 910, the entity 9999 formats and sends a purchase authorizationrequest to the Authorization Network 987 that is destined for thefunding card issuer 986. At 911, the authorization network forwards thepurchase authorization request to the funding card issuer 986. At 912,the funding card issuer provides an approved response to theauthorization request to the authorization network. At 913, theauthorization network forwards the authorization response to the entity9999. At 914, the entity 9999 forwards the authorization response to thewallet 597.

At 915, the e-wallet generates a request to the entity 9999 to initiatea payment transaction to “top up” funds to the prepaid card in theamount of the difference between the e-commerce purchase and remainingfunds on the prepaid card (this is the same purchase amount that wasapproved by the funding card issuer 986). The e-wallet provides theentity 9999 with the prepaid PAN and the amount. The prepaid PAN isassociated with the same country as the e-commerce retailer (e.g. USe-commerce retailer, US prepaid card). At 916, the entity 9999 formatsand sends a payment transaction authorization request to theauthorization network 987, that is destined for the prepaid card issuer596.

At 917, the authorization network 987 forwards the payment transactionauthorization request to the prepaid card issuer. At 918, the prepaidcard issuer 596 provides an approved response to the authorizationrequest to the authorization network 987. At 919, the authorizationnetwork forwards the authorization response to the entity 9999. At 920,the entity 9999 provides a response to the e-wallet indicating that thetop-up was approved. Flows 921 and 922 show the CVC 2 request andresponse between the wallet and prepaid card issuer. In this regard, atthe time of the purchase, once approval has been obtained from thefunding card issuer, and top-up has been successfully accomplished, tomake the purchase successful it is necessary to provide the merchantwith all the details needed to move an authorization through. Thus, themerchant will need the CVC2 data. CVC2 data is often requested by themerchant to ensure that the person making an on-line transaction reallyhas the card in his or her possession. In one or more embodiments, CVC2data is not stored and so must be obtained from the prepaid card issuer.At 921 and 922, the CVC2 value is obtained for the specific prepaid cardto be used in the purchase transaction. At 923, payment informationincluding the prepaid card PAN, expiration date, and CVC 2 (if required)is provided by the wallet to the e-commerce retailer.

At 924, the e-commerce retailer 895 generates a request to its acquirer990 to perform the e-commerce purchase against the prepaid card. At 925,the e-commerce retailer acquirer 990 formats and sends a purchaseauthorization request to the authorization network that is destined forthe prepaid card issuer. At 926, the authorization network forwards thepurchase authorization request to the prepaid card issuer 596. At 927,the prepaid card issuer 596 provides an approved response to theauthorization request to the authorization network. At 928, theauthorization network forwards the authorization response to thee-commerce retailer acquirer. At 929, the e-commerce retailer acquirer990 forwards the authorization response to the e-commerce retailer. At930, the e-commerce retailer provides purchase confirmation to theconsumer 598.

The e-commerce retailer acquirer block 990 contemplates a bank in thesame jurisdiction as the e-commerce retailer, as well as a serveroperated by or on behalf of the bank which may be located in anyjurisdiction. The balance inquiry service block 989 contemplates aserver with appropriate software which is configured to send a balanceinquiry to the prepaid card issuer to determine how much is left on thecard; such server is likely to be in the same jurisdiction as thee-wallet server, but could also be elsewhere. The prepaid card issuerblock 596 contemplates a prepaid card issuer which is likely, but notnecessarily, in the same jurisdiction as the e-commerce retailer, aswell as a server run by or on behalf of the prepaid card issuer, withsuitable software, which could be located in any jurisdiction. Thefunding card issuer block 986 contemplates a banking institution, mostlikely in the home country of the consumer, as well as a server run byor on behalf of such banking institution, with suitable software, whichcould be located in any jurisdiction. The authorization network 987 istypically a multinational network such as the BANKNET or VISANETnetworks discussed elsewhere, or payment processing networks of otheroperators. The funding purchase/payment transaction acquirer/processorblock 9999 contemplates (i) an acquirer that handles the purchase on thecard in the shopper's native country, as well as the top-up of thepre-paid card in the jurisdiction where the e-commerce retailer islocated, as well as (ii) a server run by or on behalf of such acquirer,with suitable software. The server and acquirer could be in anyjurisdiction(s) and could themselves be in the same or differentjurisdictions. In some cases, the functionality of block 9999 could besplit between two or more entities.

Due consideration of applicable legal and regulatory considerationsand/or contractual obligations should be had, inasmuch as, in someembodiments, the merchant will be accepting a card and shipping to anaddress that are not technically the consumer's funding card and actualshipping address; furthermore, in some embodiments, there also is not aphysical (prepaid or other) card being issued (it is virtual).

In those embodiments where such considerations are pertinent, dueconsideration should be given to addressing concerns of the shippingmerchant acquirer and prepaid card issuer, with respect to theirwillingness to take on the risk of sending and/or approving atransaction before settlement has occurred. In some embodiments, theshipping merchant will initiate a payment transaction authorizationrequest before settlement has occurred on the funding card purchase,and/or the prepaid card issuer will approve the e-commerce purchasebefore settlement has occurred on payment transaction.

In some cases, the prepaid card issuer will be able to restrictpurchases on the prepaid card to only those occurring through thewallet—for example, will ensure billing and/or shipping address is theshipping merchant's warehouse. In other cases, an additional indicatorwill be required in the authorization request to indicate that thetransaction was generated via the e-wallet. Other cases do not involve aseparate prepaid card and in such cases, these considerations are not aconcern.

FIG. 10 depicts an exemplary transaction at an international merchantusing a local funding card, wherein a merchant accepts foreign-issuedcards. At 1001, the consumer 598 responds affirmatively to an inquiry onwhether to proceed with checkout. At 1002, the e-commerce retailer 895generates a call to the e-wallet to retrieve payment method and confirmshipping address information. At 1003, the e-wallet 597 provides paymentinformation to the e-commerce retailer 895, including funding card PANand expiration date. In one or more embodiments, the e-wallet does notstore the funding card CVC 2, so if the e-commerce retailer requires it,the consumer will need to populate that field on the e-commerce retailersite. At 1004, the e-commerce retailer generates a request to itsacquirer 990 to perform the e-commerce purchase against the fundingcard. At 1005, the e-commerce retailer acquirer 990 formats and sends apurchase authorization request to the authorization network 987 that isdestined for the funding card issuer 986. At 1006, the authorizationnetwork 987 forwards the purchase authorization request to the fundingcard issuer 986. At 1007, the funding card issuer provides an approvedresponse to the authorization request to the authorization network. At1008, the authorization network forwards the authorization response tothe e-commerce retailer acquirer 990. At 1009, the e-commerce retaileracquirer forwards the authorization response to the e-commerce retailer895. At 1010, the e-commerce retailer provides purchase confirmation tothe consumer. At 1011, the e-commerce retailer generates a clearingmessage (e.g., message type indicator (MTI) 1240) to the clearing system1081 for the e-commerce purchase. At 1012, the clearing system sends aclearing message to the funding card issuer 986 for the e-commercepurchase. Clearing system block 1081 contemplates a business-as-usualclearing system and can be located, for example, in the USA or anotherjurisdiction. Again, some embodiments do not involve multijurisdictionalaspects and/or a local prepaid funding card.

Some embodiments of the invention pertain to virtual card numbers fordigital wallets. The following terminology is employed herein:

-   -   Virtual card number—a unique number (in at least some instances,        16 digits) that is linked in the back end to a Real Card Number        (RCN). It can be set up with sets of rules, alerts and limits        which allows tight and flexible management of payments    -   Real Card Number (RCN)—number (in at least some instances, 16        digits) written on a physical card    -   Digital wallet—host of the financial information (card numbers,        addresses, etc.)

of users to facilitate transactions with just a few clicks orinteractions

-   -   Card—A credit, debit or prepaid card    -   Consumer—The end user who patronizes physical or online stores    -   Merchant—An online or physical store    -   Remote payments—Payments made using an internet connection using        any suitable coming device: desktop, laptop, smart phone,        tablet, and the like    -   Proximity payments—Payments made using Near Field Communication    -   Near field communication (NFC)—sets of standards for devices to        use radio communication with each other by touching devices        together or bringing them into close proximity, usually no more        than a few centimeters (used herein for payment purposes)

Credit, debit and prepaid cards include a series of numbers which can beused to identify the issuing bank and the cardholder's bank account. Avirtual card number (VCN) is a randomly generated series of numberswhich does not contain any identifying information but is linked to areal card number (RCN).

A digital wallet is an electronic form of a physical wallet and housesvarious payment methods such as credit, debit and/or prepaid cardsand/or electronic cash in the form of stored value.

One of the benefits currently being offered by digital wallets isconcealing the consumer's RCN from merchants, thereby allowing consumersto make purchases from merchants that they would not be inclined to givetheir RCNs to. However, the consequence of hiding the consumer's RCNfrom the merchant is that the merchant does not know which bank's cardis being used and any promotions associated with that particular bank'scard are forgone.

By incorporating a VCN into a digital wallet, consumers are able toconceal their account information while revealing the bank that issuedthe card, thereby enjoying both the benefits of being able to purchasefrom merchants without giving them their RCNs while enjoying allpromotions associated with using a particular bank's card.

Existing payment options will now be described. One current techniqueinvolves direct payment to the merchant via a credit, debit, or prepaidcard. As seen in FIG. 11, the consumer is asked for the card information8001, shipping address (here, store pick-up 8002), and billing address8003 and the like. Referring to FIG. 12, during the review of thepayment, the consumer typically reviews all the information he or shehas input in the previous page. The merchant has access to theinformation from the consumer, including the actual card number—RCN.This option is advantageous in that it does not require any form ofregistration, the consumer is entitled to any privileges his cardaccords, the merchant processes transactions through standard processesand receives his or her settlement in his or her bank account, andexisting dispute and/or chargeback processes are available. On the otherhand, the consumer faces the risk of revealing his or her card numberand security code to the merchant, and the process is cumbersome in thatit requires the consumer to fill in many fields of information.

Another current technique involves payment made indirectly to themerchant via a digital wallet. As seen in FIG. 13, consumers areredirected to the wallet website (e.g., by selecting a wallet option“e-wal” 8004). In FIG. 14, the consumer logs in to his or her walletaccount using his or her e-mail (or other username) and password, forexample. In FIG. 15, the consumer reviews the card to be used for thepurchase and clicks on the “continue” button 8005 to confirm payment andto be redirected to the merchant site. In FIG. 16, the consumer reviewshis or her information. In this option, none of the RCN information ispassed to the merchant. The merchant only receives a payment token. Thisoption is advantageous in that consumers only need to log in instead offilling up fields of information, and in that consumers' card numbersand security codes are hidden from the merchant. On the other hand,consumers forgo any privileges their cards accord, the merchant receivespayment in his or her wallet account not his or her bank account, anddisputes and chargeback processes are different for merchants.

Still another current technique involves direct interaction with themerchant via a Virtual Card Number (also known as a Virtual AccountNumber). Here, the user logs in at 8006 in FIG. 17 with a user ID andpassword or the like, and at 8007 is provided with the virtual cardnumber. In FIG. 18, the user will then enter the virtual cardinformation from 8007 into the corresponding fields 8008.Advantageously, the consumer's real card number and security code arehidden from the merchant. On the other hand, there is a relativelyunintuitive user experience wherein the consumer needs to leave thecurrent transaction to go to his or her bank's website 8006 to generatea VCN 8007 (typically by swapping between windows or tabs of his or herbrowser); further, like the first current option, this is a cumbersomeprocess that requires the consumer to fill in many fields ofinformation.

Referring now to FIG. 19, an exemplary sequence of steps in accordancewith an embodiment of the invention will now be described, wherein theconsumer makes remote payments via a VCN-enabled digital wallet. At8009, the user selects the VCN-enabled digital wallet “E-wallet” as thepayment option. The consumer is thus redirected from the merchant website to the E-wallet web site. At 8010 in FIG. 20, the consumer signs inusing his or her email address or the like, or signs up for an accountif he or she does not already have one. At 8011 in FIG. 21, the consumeris greeted by name and a personal message of his or her choosing isdisplayed. If both the name and the personal message are correct, he orshe proceeds with keying in his or her password. In FIG. 22, theconsumer can select an RCN or VCN that is already in his or her wallet,as at 8012; create a VCN for a single transaction by clicking on the“Use VCN” button 8013 next to his or her RCN; or add a new a new RCN orVCN to his or her wallet by clicking on the “Add Card” button 8014.Optional functionality can be provided for adding and/or managing VCNs.If the consumer desires to manage the VCN rules, limits and alerts, heor she does so through the interface itself. In the right-hand column,various shipping address options can be provided, e.g., “Home(default)”, “Vacation Home,” and “Dad's House.” FIG. 23 is anon-limiting example of such a management interface. As seen in FIG. 24,once the consumer has chosen the card he or she wishes to use, he or shewill click on a “Review Your Order” button to be redirected back to themerchant site to complete his or her transaction; the merchant web site,at 8015, displays the VCN and not the RCN.

Advantageously, in this embodiment, consumers can generate a VCN to beused only for a specific transaction; consumers can create multiple VCNsto be used for different purposes and can specify the expiry date or thenumber of times that a VCN can be used; and/or consumers can setcontrols on their VCNs such as asking to be alerted or having thetransaction declined if, for example, the transaction amount is beyond astated limit, the amount spent on the VCN has reached its daily limit,and/or spending for a particular category has reached its limit.

In another aspect of the invention, proximity payments are made via NFCwallets. A virtual card number can be used for proximity payments inaddition to remote payments via mobile payment technology. Instead ofloading an actual credit card into the wallet, a VCN can be used insteadwhen the consumer is wary of the merchant. Advantages of this aspect aresimilar to those discussed above for the remote payment aspect.

FIG. 25 shows an exemplary transaction flow. During a one-timepre-requisite and set-up process 8017, as seen at 8020, one or moreconsumers 598 register with digital wallet 597, and add card andshipping details on the wallet. Furthermore, as seen at 8021, merchant1999 integrates with the wallet 597 and places the wallet's payment markon the merchant's web site 1999. Note that reference character 1999 isused in FIG. 25 to refer to both the merchant and the merchant's website. The steps 8020, 8021 can be carried out, for example, using module1483 or 5483.

In a payment phase 8018, as seen at 8022, consumer 598 accesses themerchant's web site 1999, or accesses some other application of themerchant, and makes a purchase. As seen at 8023, the consumer isredirected to the wallet 597 at checkout. At step 8024, the consumerselects an existing VCN or creates a new VCN to be used. In step 8025,the wallet 597 passes the VCN details back to the merchant 1999. In step8026, as part of the check-out review process, the details are shown tothe consumer 598. In step 8027, the consumer 598 reviews the details andconfirms payment. In step 8028, the merchant passes all the informationto acquirer 990 which sends it to the issuer (not shown) over network987. In step 8029, the operator of the network 987 uses MasterCardInControl® PAN (primary account number) mapping functionality 8016 toaccess a table or the like to map the VCN of the transaction to thecorresponding RCN, before passing same to the issuer (registered mark ofMasterCard International Incorporated, Purchase, N.Y. USA).

Other processes are shown at 8019. As seen at 8030, 8031, settlement andchargeback and/or reversal processes may be conventional, i.e., businessas usual or “BAU.”

In some cases, as discussed elsewhere herein, a suitable application 12resides on a smart phone 1420, 10 or the like and such phone ispresented to a terminal 126 or the like at a brick and mortar location.The application 12 includes or has access to one or more locally storedVCNs and/or one or more locally stored offers 5994.

Thus, one or more embodiments of the invention are directed to, and/oradvantageously work in conjunction with, an electronic wallet(e-wallet), also known as a digital wallet. As noted, an e-walletprovides consumers with a secure and convenient way to pay for purchasesfrom accepting on-line merchants. Upon registration, consumers may storetheir card, billing and shipping information on a site hosted by asuitable entity (for example, an operator of a payment network 2008),and may access that information to pay conveniently and securely acrossparticipating merchants. The e-wallet platform may deliver additionalsecurity with the use of “virtual” account numbers to mask cardholders'real information.

In some cases, the aforementioned use of “virtual” account numbers, alsoknown as PAN mapping, can be, for example, a network service that anoperator of a payment network 2008 (e.g., an entity such as MasterCardInternational Incorporated) provides to issuers; in other instances,issuers may elect to use their own solution. The PAN mapping processinvolves taking the original Primary Account Number (PAN) and issuing apseudo-PAN (or virtual card number) in its place. This provides securityagainst the possibility of the original PAN becoming compromised. Anon-limiting example of PAN mapping is that offered under the “one timeuse number” feature of MasterCard International Incorporated'sinControl™ payment solutions platform. The skilled artisan will befamiliar with a variety of PAN mapping techniques, and, given theteachings herein, will be able to adapt same to one or more embodimentsof the invention. For example, the payment network operator may create atranslation table wherein external-facing instances of the numberpresent the pseudo-PAN while internal-facing instances present theactual PAN. Commercially available PAN-mapping solutions which may beadapted to embodiments of the invention, given the teachings herein,include those available from Orbiscom Ltd., Block 1, Blackrock BusinessPark, Carysfort Avenue, Blackrock, Co. Dublin, Ireland (now part ofMasterCard International Incorporated of Purchase, N.Y., USA); by way ofexample and not limitation, techniques of U.S. Pat. Nos. 6,636,833 and7,136,835 of Flitcroft et al., the complete disclosures of both of whichare expressly incorporated herein by reference in their entireties forall purposes.

For the avoidance of doubt, it is to be emphasized that MasterCardInternational Incorporated's inControl™ payment solutions platform is anon-limiting example, and many different techniques can be used toprovide the “virtual number” described elsewhere herein, whether PANmapping as described in the Flitcroft et al. patents or otherwise.

It should be noted that the person of ordinary skill in the art will befamiliar with e-wallets per se, and, given the teachings herein, will beable to adapt same for implementing one or more embodiments of theinvention. Non-limiting examples of known e-wallets include the PayPalservice (mark of PayPal subsidiary of eBay, Inc., San Jose, Calif.,USA); the Checkout by Amazon service (mark of Amazon.com, Inc., Seattle,Wash., USA); and the Google Checkout service (mark of Google, Inc.Mountain View, Calif., USA).

One or more embodiments advantageously employ a virtual card numberinside the convenient user experience offered by an e-wallet. Asdiscussed, a virtual card number advantageously offers an incrementallevel of security and trust from consumers (particularly in cross-borderuse cases where consumers are not familiar with the merchant that theyare buying from); the possibility of implementing alerts, limits (time,amounts and number of transactions, merchant category, etc.); and/orrisk management. On the other hand, a virtual card number isinconvenient in that it provides a cumbersome user experience where theconsumer needs to swap between his or her virtual card number generator(browser, desktop plug-in, etc.) and his or her payment experience(merchant site).

As also discussed, the wallet offers the advantages that the consumerpays via mouse clicks or the like without even pulling his or her cardsfrom his or her wallet (nor leaving the merchant's website); however, itis inconvenient in that the consumer needs to trust the merchant wherethe wallet application passes the card number to the merchant forprocessing; and the wallet may or may not offer a level of riskmanagement that can offer liability shift for merchants.

Advantageously, one or more embodiments integrate a virtual card numberand an e-wallet. In one or more embodiments, merchants do not need tochange any integration to employ the e-wallet with virtual card number.Furthermore, in one or more embodiments, the difference between themerchant getting paid with a virtual card number or a real card numberis transparent to the merchant.

In one or more embodiments, consumers are able to select, during theirpayment experience, when they want to use a VCN for a specifictransaction, using only a few mouse clicks or the like. Pertinent usecases for one or more embodiments include the case where the consumerdesires to have better control over alerts and/or limits for aparticular card number or when he or she lacks trust in the merchants orcountry that he or she is buying from.

Consider now a current wallet payment experience. As seen in FIG. 26,the user has several items in his or her shopping cart and is affordedan opportunity, at 8032, to select a desired shipping option, as well asan option for a desired payment method, e.g., conventional checkout 8033or an E-wallet checkout 8034. In FIG. 27, at 8035, the user identifieshimself or herself to the wallet using credentials; e.g., e-mail addressor mobile phone number. In FIG. 28, at 8036, the user enters his or herpassword. In FIG. 29, the user selects from among several differentpayment cards, at 8037, and from among several different shippingaddresses, at 8038. In the right-hand column, various shipping addressoptions can be provided, e.g., “Home (default)”, “Vacation Home,” and“Dad's House.” In FIG. 30, the user returns to the merchant site andconfirms the details. In FIG. 31, a payment complete page is displayedto the user.

Payment Experience With VCN Imbedded in the Wallet

With attention now to FIG. 32, in a first step, the user is at ashopping cart screen designated generally as 8039, has the option, shownat 8040, to select from several different shipping options, and is alsoafforded payment method selection options 8041 (conventional) and 8042(E-wallet). In FIG. 33, at 8201, the user identifies himself or herselfto the wallet using credentials; e.g., e-mail address or mobile phonenumber. In FIG. 34, at 8043, the user enters his or her password. InFIG. 35, the user selects from among several different payment cards, at8044, and from among several different shipping addresses, at 8045. InFIG. 36, the user chooses to use a VCN for the given transaction, asseen at 8046. In FIG. 37, the user optionally chooses to change limitand/or alert parameters for the VCN, using the MASTERCARD INCONTROL®platform or the like (registered mark of MasterCard InternationalIncorporated, Purchase, N.Y., USA; functionality allows customers toestablish customized spend management controls). As seen at 8047, theuser may set a dollar limit for a single transaction or for spending ina certain period of time, and may choose to decline transactions thatare over the limit or to receive an alert regarding same. As seen at8048, the user may set a dollar limit for spending in a certain categoryin a certain period of time, and may choose to decline transactions thatare over the limit or to receive an alert regarding same. As seen inFIG. 38, the user returns to the merchant site and confirms the details.In FIG. 39, a payment complete page is displayed to the user. Note thatin general, some embodiments involve leaving the merchant web site andreturning thereto, while others involve a seamless experience wherein awallet or the like is closely integrated with the merchant web site viaan API or the like.

Cross Border Shipping for Digital Wallets

In another aspect, one or more embodiments pertain to cross-bordershipping for digital wallets.

Many foreign consumers now have a strong desire to shop overseas in theUS and the UK. The US and UK are perceived as providing more options,better pricing, and a more pleasant experience in shopping. Manyconsumers go to the US on shopping sprees from all over the world.

In addition, broadband capability has been increasing around the world,often growing 150% on a yearly basis. There is also a stronger middleclass in rapidly developing nations such as Brazil, India, China, andRussia. Consumers from these jurisdictions are finding their way tomerchant web sites in the US and UK. 19% of all the browsing done on USe-merchants today is from consumers in other countries. However, USmerchants for the most part do not accept foreign cards due to liabilityconcerns. About 40% do accept foreign cards online; however, they acceptforeign cards from only a handful of countries; say, 10-30 countries.Even when they do accept foreign cards, they typically do not shipoverseas. Thus, there are barriers to both acceptance and fulfillmentfor foreigners wishing to purchase from US e-merchants.

Even for a US merchant that does ship all over the world, overseasshoppers have transparency issues as they may not be advised what taxes,customs duties, and the like will be due when the order arrives in theirparticular country; in some instances, they may not even be aware of theshipping charges.

As used in this discussion, the “domestic address” is the consumer'saddress in his or her country of residence; the “overseas address” isthe consumer's address in the country of the merchant; “domesticshipping” is shipping from the merchant's warehouse to the consumer'soverseas address; and “overseas shipping” is shipping from theconsumer's overseas address to the domestic address.

Lower prices and the availability of the product are driving consumersto go online to purchase products from overseas. However, a commonlyencountered problem is that merchants do not provide internationalshipping, typically offering only domestic shipping.

Currently, service providers (also referred to as logistics providers,logistics partners, or shipping merchants) such as Borderlinx offer asolution to this problem by providing consumers with an overseas addressthat the merchant can ship the consumer's purchased good to. Goodsshipped to the overseas address can be stored free of charge for 30 daysin order to accumulate goods and ship one large package instead of manysmaller packages. Goods can also be combined with those of family andfriends to create a larger package. Once the consumer requests thepackage to be shipped from his or her overseas address to his or herdomestic address, the fully landed costs (including taxes and duties)are calculated and the consumer is able to make full and final paymentfor the cross border shipping service.

However, there are several limitations to this service as follows:

-   -   Consumers will not know the cost of overseas shipping at the        time of purchasing their goods as this service is provided by a        third party and not the merchant.    -   Consumers have to wait several days to finalize their        transactions as they have to wait for their goods to arrive at        their overseas address before they can arrange shipping to their        domestic address.    -   Consumers have to go to two different websites on two separate        days to complete their transactions as they have to deal with        two parties—the merchant and the service provider.

Advantageously, one or more embodiments improve the consumer experienceby integrating the merchant with the service provider. In at least someinstances, using information from the merchant regarding the weight ofthe goods and the size of the packaging together with the serviceprovider's shipping charges, an exemplary embodiment of an e-walletprovides consumers with the cost of shipping at the time of purchase.Consumers are therefore able to arrange overseas shipment without havingto wait for their goods to be delivered to their domestic addresses;furthermore, they only need to transact with one entity, namely, thee-wallet.

Furthermore, in one or more embodiments, an e-wallet in accordance withaspects of the invention allows consumers to compare prices acrossservice providers in order to ship their goods at the lowest cost.

Even further, in one or more embodiments, an e-wallet is provided by anentity such as an operator of payment network 2008; such entity in turnpreserves the value added features of an international shipping serviceprovider such as bundling goods or repacking in order to lower shippingcost.

Referring now to FIG. 40, in a current approach to shipping options,using an international shipping service provider, consumers register onthe service provider's website and are given an address 8049 in thecountry of the merchant. As seen in FIG. 41, the user enters his or herbilling address. As seen in FIG. 42, when the user selects a shippingoption, he or she uses his or her domestic address as his or her billingaddress, and the overseas address that he or she was given as his or hershipping address, as at 8050. In FIG. 43, the consumer selects thedomestic shipping method. Here, the consumer chooses “standard ground.”In FIG. 44, the consumer selects a payment method—here, the “E-Wal”electronic wallet is chosen. In FIG. 45, the consumer reviews his or herorder and confirms his or her purchase via “submit order” button 8051.Then, in FIG. 46, once the package arrives at the overseas address, theconsumer selects his or her overseas shipping method and makes paymentfor the overseas shipping. Here, the user has chosen 2-day shipping.

The current approach just discussed has the advantage that consumersfollow the same purchasing process that they are familiar with, canconsolidate packages and ship one large package instead of many smallpackages, and can repack their packages to reduce shipping charges. Onthe other hand, in this current approach, consumers do not know the costof overseas shipping at the time of purchase, consumers have to waittill the package arrives at their overseas address to arrange overseasshipping, and consumers have to transact with the merchant and theinternational shipping service provider independently.

Consider now an exemplary approach in accordance with an aspect of theinvention. Referring to FIG. 47, using an e-wallet in accordance with anaspect of the invention, the consumer selects the “E-wallet” as his orher payment method, as seen at 8052. In FIG. 48, the consumer isre-directed to the “E-wallet” web site where he or she uses his or hercredentials to log in (e.g., sign on at 8053 using e-mail or mobilephone number as an ID and then enter password at 8054). If not alreadyregistered, at 8055 the consumer is afforded an option to sign up. InFIG. 49, the E-wallet determines whether the merchant will ship to theuser's domestic address. If not, as seen at 8056, the e-wallet providesthe option to the consumer to use an international shipping serviceoffered by “Acme Logistics Providers.” In FIG. 50, the E-walletdetermines the cost of cross border shipping and presents severaloptions 8057 for the consumer to choose from. The first option isshipping speed. The second option is the shipping charges by variousinternational shipping providers and the merchant themselves ifapplicable. The user can confirm his or her selection at 8058.Optionally, if consumers wish to consolidate their goods, they also havethe option, as at 8059, to ship domestically to their overseas addresses(e.g., warehouse). In FIG. 51, the consumer reviews the shipping chargesbefore proceeding to reviewing his or her order (button 8060) and makingpayment. Local shipping charges apply for domestic shipping while bothlocal shipping and overseas shipping charges apply for overseasshipping. In one or more embodiments, the domestic shipping charge isbased on the consumer's selection at the merchant's website.

Advantageously, in this approach, consumers do not need to go throughthe inconvenience of filling in their billing addresses, shippingaddresses or credit card information as their digital wallets alreadyhave this information. Furthermore, consumers know how much the totalshipping charges will be before deciding if they wish to proceed with apurchase. As more international shipping services are added to theE-wallet, consumers are able to compare shipping prices across variousservice providers. Consumers have the flexibility of concluding thetransaction immediately or consolidating packages at their overseasaddresses.

FIG. 52 compares current techniques 8071 with a sequence of steps 8072in accordance with an embodiment of the invention. In step 8073, theconsumer visits the merchant's web site. In step 8074, the user addsgoods to his or her cart. In step 8075, the user navigates to his or hershopping cart to check out. These steps are common to both approaches8071, 8072. In the current technique, at 8076, the user inputs his orher billing and shipping addresses. At 8077, he or she selects thedomestic shipping method. In step 8078, he or she selects the paymentoption. In step 8079, he or she reviews and confirms his or her order.In step 8080, the consumer must typically wait a certain number of days(“X”) for the goods to be delivered to the overseas address. In step8081, the consumer receives a delivery notification from the logisticsprovider (e.g., ACME). In step 8082, he or she logs in to the logisticsprovider's web site. In step 8083, the consumer decides whether to shipnow or to bundle with other goods. In step 8084, the consumer confirmsand makes payment.

In a sequence of steps 8072 in accordance with an embodiment of theinvention, at step 8085, the user selects the domestic shipping method.In step 8086, he or she selects the E-wallet as his or her paymentoption. In step 8087, the user logs in to the E-wallet. In step 8088,the user selects the credit card to be used for payment and the shippingaddress. In step 8089, the user selects the shipping cost and pace(i.e., whether to ship now or to bundle). In step 8090, the consumerreviews and confirms the order.

In FIG. 52, it will be appreciated that steps 8073-8079, 8085, and 8086pertain to the merchant's web site; steps 8087-8090 pertain to theE-wallet; and steps 8081-8084 pertain to the logistics provider.

FIG. 53 presents an exemplary transaction flow. During a one-timepre-requisite and set-up process 8102, as seen at 8105, one or moreconsumers 598 register with digital wallet 597, and add card andshipping details on the wallet. Furthermore, as seen at 8106, merchant1999 integrates with the wallet 597. Note that reference character 1999is used in FIG. 53 to refer to both the merchant and the merchant's website. The steps 8105, 8106 can be carried out, for example, using module1483, 5483, with assistance from a GUI 1477, 5477 in at least somecases.

In a payment phase 8103, as seen at 8107, consumer 598 accesses themerchant's web site 1999, or accesses some other application of themerchant, and makes a purchase. As seen at 8108, the consumer isredirected to the wallet 597 at checkout. In step 8109, the e-wallet 597obtains the product details from the merchant 1999. In step 8110, thee-wallet 597 obtains the shipping cost from the logistics provider 8101.In step 8111, the e-wallet 597 shows the product and shipping costs tothe consumer 598 for review. In step 8112, the consumer 598 reviews thedetails and confirms payment. In step 8113, the e-wallet passes all theinformation to the acquirer 990 for business as usual (“BAU”) processingvia network 987. In step 8114, the e-wallet 597 passes the order to boththe merchant 1999 and the logistics provider 8101.

Other processes are shown at 8104. As seen at 8115, 8116, settlement andchargeback and/or reversal processes may be conventional, i.e., BAU.

In some cases, as discussed elsewhere herein, a suitable application 12resides on a smart phone 1420, 10 or the like and such phone ispresented to a terminal 126 or the like at a brick and mortar location.The application 12 includes or has access to one or more locally storedVCNs and/or one or more locally stored offers 5994.

FIG. 54 shows an alternative exemplary software architecture diagram.Unless otherwise indicated, elements therein have a similarfunctionality to elements on FIG. 5 (corresponding portions of thewallet and database have had their reference characters incremented byfour thousand). Wallet platform 5497 includes executable code, stored ina non-transitory manner in a tangible computer-readable recordablestorage medium, which, when loaded into the memory of one or moreservers, causes one or more processors thereof to implement at leastportions of the logic described herein. Database 5479 includes asuitable database program such as the Oracle DBMS, Access and SQL Serverfrom Microsoft, DB2 from IBM and the Open source DBMS MySQL, stored in anon-transitory manner in a tangible computer-readable recordable storagemedium, as well as persistent storage to store the records therein. Thedatabase program, when loaded into the memory of one or more servers,causes one or more processors thereof to implement the database(s)described herein (e.g., with pre-registration information). The variousinterface modules include executable code, stored in a non-transitorymanner in a tangible computer-readable recordable storage medium, which,when loaded into the memory of one or more servers, causes one or moreprocessors thereof to implement the interface functionality andcommunication flows described herein, included any needed datatranslation between the wallet platform and the external entities. GUI5477 provides an interface to consumer 598; optional shipping merchantinterface module 5475 provides an interface to shipping merchant 599;e-commerce retailer interface module 5473 provides an interface toe-commerce retailer 895. Furthermore, registration module 5483interfaces with consumer 598 via GUI 5477 to perform registration and(optionally) maintenance functions; new data and/or updates can bestored in database 5479.

API 5999 is exposed to e-commerce retailer to allow integration of a website of retailer 895 with platform 5497. Optional PAN mapping engine5998 (optional in the sense that in some cases a PAN mapping engineexternal to the wallet 5497 can be employed) converts between VCNs andRCNs (e.g., via techniques disclosed in the Flitcroft patents); optionalapp store 5996 (optional in the sense that in some cases an app storeexternal to the wallet 5497 can be employed, and completely optional inembodiments not using smart phones or the like) makes app 12 availablefor download (the term “store” does not necessarily imply a fee).Payment method engine 5997 allows the electronic wallet platform 5497 toaffording consumers an option to select from multiple methods to pay fora transaction. The multiple methods (including one or more VCNs) arebased, at least in part, on the registration information. Thisinformation can be stored in database 5479 and accessed and selected byengine 5997. Optional shipping engine 5995 determines shipping options;for example, based on data in database 5497 and/or based on a real-timelink with one or more shipping companies. Engine 5995 also optionallycalculates sizes and shapes of shipments and determines packagingrequirements.

Comparison Aspects

Some embodiments provide a comparison of prices across shipping servicesand merchant shipping. For example, in some cases, for both domestic andcross border shipping, the E-wallet provides consumers with severaloptions. For domestic shipping, consumers have the choice between theshipping options offered by the merchant and other shipping servicesthat operate domestically such as the postal service. For overseasshipping, consumers have several shipping services to choose from suchas Borderlinx and Comgateway. Based on these options, consumers can finda combination of price, speed, reliability, and so on that is as closeto their ideal as possible.

In another aspect, offers and incentives to use a specific fundingsource may be available. In some instances, the e-wallet aggregatesvarious payment methods such as credit cards and mobile phone billing.Within each payment method, there can also be several options such ascredit cards from various issuers and payment service providers. Thee-wallet applies any relevant promotions across and within fundingsources; displays to the consumer determine which funding source in theconsumer's wallet provides the consumer with the lowest price option.Consumers are also able to view the price using each of their fundingsources, with the associated promotions, thus creating the pricedifferential.

In still another aspect, issuer promotions are passed through to theconsumer regardless of the PAN mapping technique used (e.g., VCN orvirtual prepaid card). In order for consumers to receive the promotionsoffered by their credit card issuers, the virtual card needs to eitherhave the same bank identification number (BIN) as the real card or bemapped to the real card. The e-wallet can provide this functionalitywhen either the VCN or virtual prepaid card is used.

In a further aspect, using a virtual card number (VCN) as a complementor replacement to the virtual prepaid card, the e-wallet can potentiallyuse VCNs for both cross border and domestic transactions.

In addition, the consumer experience can be varied in several ways, suchas having the e-wallet appear as a pop up window, wherein the consumercompletes the transaction on the merchant site or wherein the consumeris redirected to the e-wallet site after checking out from the merchantsite, completing the transaction on the wallet site.

In a still further aspect, in some embodiments, a “best deal cardselector” is provided. In this aspect, the consumer registers creditcards (generally understood to include also debit, prepaid, and/orstored value cards in at least some cases) from various financialinstitutions onto his or her e-wallet. Each credit card comes withpromotions that apply to selected merchants. When making a payment atone of these selected merchants, the consumer selects a credit card touse within his or her e-wallet and places his or her mobile phone overthe proximity card reader. The e-wallet detects the merchant and checksfor promotions associated with that merchant across all the paymentcards in the wallet. If a better offer is found (in terms of paying thelowest price or otherwise (e.g., points or rewards)), the transaction ispaused and an alert is sent to the consumer informing him or her aboutthe better offer with the option to change the card used for payment.The consumer either chooses to continue with the current card or choosesa new card and places the mobile phone over the proximity card reader tocomplete the transaction.

Recapitulation

Given the discussion thus far, it will be appreciated that, in generalterms, an exemplary method, according to an aspect of the invention,includes the step of obtaining, at an electronic wallet platform 5497,registration information for a plurality of consumers 598. This step canbe carried out, for example, using registration module 5483, in at leastsome cases, via GUI 5477. Another step includes providing a mechanism tointegrate the electronic wallet platform with a plurality of merchants1999 (an e-commerce retailer 895 is a non-limiting example of amerchant). This step can be carried out, for example, by exposing an API5999 to the merchants.

A further step includes, via the electronic wallet platform 5497,affording a given one of the consumers an option to select from multiplemethods to pay for a transaction with a given one of the merchants 1999.The multiple methods are based, at least in part, on the registrationinformation. At least one of the multiple methods includes a virtualcard number (VCN). As used herein, and as noted above, a virtual cardnumber (VCN) is a randomly generated series of numbers which does notcontain any identifying information but is linked to a real card number(RCN). Confusion should be avoided with the terminology “virtual card”as may be used in the case where an RCN is stored in some kind of deviceand a transaction occurs without a physical card corresponding to theRCN being present, yet where the RCN is supplied to the merchant. Thestep discussed in this paragraph can be carried out, for example,directly with the consumer via GUI 5477 or through the intermediary ofthe merchant, using e-commerce retailer interface module 5473; in eithercase, with the assistance of payment method engine 5997. An examplescreen is shown in FIG. 35.

A still further step includes obtaining, from the given one of theconsumers, a selection of the virtual card number for payment for thetransaction. The step discussed in this paragraph can be carried out,for example, directly with the consumer via GUI 5477 or through theintermediary of the merchant, using e-commerce retailer interface module5473; in either case, with the assistance of payment method engine 5997.An example screen is shown in FIG. 36.

An even further step includes providing the given one of the merchantswith the virtual card number. This step can be carried out, for example,by exposing API 5999 to the merchant. This facilitates the merchantbeing paid for the transaction. The given one of the merchants isprovided with the virtual card number and the amount of the transactionis charged against an actual card number, not provided to the merchant,to which the virtual card number is linked.

Some embodiments further include intercepting an authorization request,from the given one of the merchants, for an amount of the transaction tobe charged against the virtual card number; translating the virtual cardnumber into an actual card number which is not provided to the merchant;and passing the authorization request to an issuer, with the actual cardnumber therein. These steps can be carried out, for example, with anaccount number mapping engine 5998 within a payment network (e.g.,2008).

In some instances, the transaction includes an online transaction at aweb site of the given one of the merchants 1999, and the selection ofthe virtual card number is obtained at the electronic wallet platformfrom a computing device of the given one of the consumers (e.g., a PC orlaptop generally represented by system 300 in FIG. 8).

In some cases, a further step includes providing a system. The systemincludes distinct software modules. Each of the distinct softwaremodules is embodied on a non-transitory computer-readable storagemedium. The distinct software modules include a registration module5483, a user interface module 5477, an application program interface5999, and a payment method engine module 5997. The steps are thencarried out or otherwise facilitated by the modules, as set forth above.In some cases, the distinct software modules further include an accountnumber mapping engine module 5998, and further steps includeintercepting an authorization request, from the given one of themerchants, for an amount of the transaction to be charged against thevirtual card number, by executing the account number mapping enginemodule on the at least one hardware processor; translating the virtualcard number into an actual card number which is not provided to themerchant, by executing the account number mapping engine module on theat least one hardware processor; and passing the authorization requestto an issuer, with the actual card number therein, by executing theaccount number mapping engine module on the at least one hardwareprocessor.

It is worth noting that the wallet can pop-up at the merchant web siteor the consumer can be redirected to the e-wallet site.

One or more embodiments thus contemplate an apparatus, such as a serveron which electronic wallet platform 5497 runs, including a memory, andat least one processor, coupled to the memory, and operative to carryout any one, some, or all of the method steps just described. In one ormore embodiments, distinct software modules stored in a non-transitorystorage medium, when loaded in to the memory, configure the at least oneprocessor to be operative to carry out any one, some, or all of themethod steps just described. As noted, the modules can include aregistration module 5483, a user interface module 5477, an applicationprogram interface 5999, a payment method engine module 5997, andoptionally, an account number mapping engine module 5998 and/or ane-commerce retailer interface module 5473.

In some instances, the transaction includes the given one of theconsumers presenting a payment device (e.g., a “smart” phone 10), havingan electronic wallet application 12 thereon, at a point-of-sale terminal124, 126 of the given one of the merchants, and the virtual card numberis provided to the merchant via communication between the payment deviceand the point-of-sale terminal of the given one of the merchants (e.g.,via NFC). In such cases, an exemplary method includes the step ofobtaining, at an electronic wallet platform, registration informationfor a plurality of consumers. Registration can be carried out, forexample, using registration module 5483 and UI 5477. A further stepincludes making available to the consumers a secure application forportable devices of the consumers which affords the consumers an optionto select from multiple methods to pay for transactions with merchants.The multiple methods are based, at least in part, on the registrationinformation. At least one of the multiple methods includes a virtualcard number. This step can be carried out, for example, usingapplication store 5996. The terminology “store” does not necessarilyimply that a fee is charged to download the application. The VCN(s) mayby provided along with the application download or may be generated anddownloaded at a later time.

It should be noted that a VCN is a payment method that is based, atleast in part, on registration information in the sense that theregistration information allows linking with the actual card number. Ofcourse, the VCN itself, in at least some instances, can be dynamicallycreated (i.e., the actual VCN may be created dynamically after theregistration process). Nevertheless, with this understanding, the VCN isstill understood to be based, at least in part, on the registrationinformation.

A further step includes intercepting an authorization request, from agiven one of the merchants, for an amount of a given one of thetransactions to be charged against a given one of the virtual cardnumbers. The given one of the transactions includes a given one of theconsumers presenting a given one of the portable devices, having thesecure application thereon, at a point-of-sale terminal of the given oneof the merchants. The virtual card number was provided to the merchantvia communication between the given one of the portable devices and thepoint-of-sale terminal of the given one of the merchants. This step canbe carried out, for example, with the account number mapping engine 5998within the payment network (e.g., 2008).

Still further steps include translating the given one of the virtualcard numbers into an actual card number which is not provided to thegiven one of the merchants; and passing the authorization request to anissuer, with the actual card number therein. These steps can be carriedout, for example, with the account number mapping engine 5998 within thepayment network (e.g., 2008).

In some cases, a further step includes providing a system. The systemincludes distinct software modules. Each of the distinct softwaremodules is embodied on a non-transitory computer-readable storagemedium. The distinct software modules include a registration module5483, a user interface module 5477, an application store module 5996,and an account number mapping engine module 5998. The steps are thencarried out or otherwise facilitated by the modules, as set forth above.

One or more embodiments thus contemplate an apparatus, such as a serveron which electronic wallet platform 5497 runs, including a memory, andat least one processor, coupled to the memory, and operative to carryout any one, some, or all of the method steps just described. In one ormore embodiments, distinct software modules stored in a non-transitorystorage medium, when loaded in to the memory, configure the at least oneprocessor to be operative to carry out any one, some, or all of themethod steps just described. As noted, the modules can include aregistration module 5483, a user interface module 5477, an applicationstore module 5996, and an account number mapping engine module 5998.

Given the discussion thus far, it will be appreciated that, in generalterms, one or more embodiments contemplate an exemplary method ofproviding a secure on-line shopping experience at an e-commerce retailerlocated in a first country to a plurality of consumers in at least onecountry other than the first country. The consumers have physicaladdresses (domestic addresses) in the at least one country other thanthe first country.

An optional step includes obtaining, at an electronic wallet server 597,from the plurality of consumers 598, registration information. Theregistration information in turn includes at least name, physicaladdress in the at least one country other than the first country, andfunding payment card account information. The aforementioned optionalregistration step can be carried out, for example, by interactionbetween the wallet platform 597 and consumer 598, facilitated by asuitable consumer user interface such as graphical user interface (GUI)1477. GUI 1477 may include, for example, HTML served out from a serveror servers on which platform 597 runs to a browser on a machine ofconsumer 598. The registration information can be stored in database1479. Registration and account maintenance module 1483 also takes partin the registration (and account maintenance) process, interfacing withthe consumer via GUI 1477. Optionally, the registration includesobtaining the information via one of a browser using a secure socketlayer and a secure hypertext transfer protocol uniform resource locator,and the registration information is stored in database 1479 in anencrypted manner accessible to the electronic wallet server but shieldedfrom the e-commerce retailer.

A further step includes facilitating assigning, to the plurality ofconsumers, local shipping addresses (overseas addresses) in the firstcountry. This step may be carried out, for example, by shipping merchantinterface module 1475.

A still further step includes obtaining, at the electronic walletserver, in connection with an on-line shopping session of a given one ofthe consumers at the e-commerce retailer 895, a request, from thee-commerce retailer, for a corresponding one of the local shippingaddresses assigned to the given one of the consumers; and an evenfurther step includes supplying the corresponding one of the localshipping addresses to the e-commerce retailer in response to the requesttherefor. These steps may be carried out, for example, by e-commerceretailer interface module 1473 interfacing with database 1479.

An even further step includes obtaining, at the electronic walletserver, in connection with the on-line shopping session of the given oneof the consumers at the e-commerce retailer, product information and anindication of a desired form of shipping from the e-commerce retailer tothe corresponding one of the local shipping addresses (domesticshipping). This step can be carried out in a variety of ways. In somecases, this information is provided to the wallet 597 from thee-commerce retailer 895, and the steps are carried out by the e-commerceretailer interface module 1473. On the other hand, in some cases, thisinformation comes from the consumer 598 via a suitable consumer userinterface such as GUI 1477.

Another step includes obtaining, at the electronic wallet server, inconnection with the on-line shopping session of the given one of theconsumers at the e-commerce retailer, an indication of a desired form ofshipping from the corresponding one of the local shipping addresses to acorresponding one of the physical addresses in the at least one countryother than the first country (overseas shipping). This step can also becarried out in a variety of ways. In some cases, this information isprovided to the wallet 597 from the e-commerce retailer 895, and thesteps are carried out by the e-commerce retailer interface module 1473.However, in other instances, this information comes from the consumer598 via a suitable consumer user interface such as GUI 1477.

It is worth noting at this point that in some cases, interaction betweenconsumer 598 and retailer 895 is used to specify the desired form ofshipping from the e-commerce retailer 895 to the shipping merchant 599.Retailer 895 then provides this information to wallet 597. Fully landedcost includes, inter alia, costs for shipment from warehouse of merchant895 to shipping merchant's warehouse 599, as well as costs for shippingfrom the shipping merchant's warehouse 599 to the consumer's physicaladdress in his or her home country. However, retailer 895 typically doesnot care how shipment occurs from the shipping merchant's warehouse 599to the consumer's physical address in his or her home country. Thus, insome cases, the wallet 597 obtains product information and localshipping information from e-commerce retailer 895. In some instances,the actual shipment from shipping merchant 599 to the consumer'sphysical address in his or her home country happens once it is knownthat the goods have been shipped from retailer 895 to warehouse 599. Insome cases, the steps discussed just above are directed to an estimatefor shipment from shipping merchant 599 to the consumer's physicaladdress in his or her home country, used to develop an estimated fullylanded cost. For purposes of estimating the fully landed cost, in anon-limiting example, consumer 598 interacts directly with wallet 597via user interface 1477 or the like, to indicate how he or she wants thegoods shipped to his or her home country from shipping merchant 599. Asnoted, however, in some cases the retailer 895 acts as an intermediary.

Yet another step includes dispatching, from the electronic walletserver, an indication, destined for the given one of the consumers, ofan estimated fully landed cost associated with the on-line shoppingsession. The estimated fully landed cost is based at least upon theproduct information, the indication of the desired form of shipping fromthe e-commerce retailer to the corresponding one of the local shippingaddresses, and the indication of the desired form of shipping from thecorresponding one of the local shipping addresses to the correspondingone of the physical addresses in the at least one country other than thefirst country. This step may be carried out, for example, via userinterface 1477 or the like (e.g., GUI 1477 serves HTML, code to theconsumer's machine that causes another window to pop up thereon);however, in some cases the retailer 895 acts as an intermediary.

An additional step includes dispatching, from the electronic walletserver 597, shipping option information, destined for the given one ofthe consumers 598. The shipping option information provides at least twooptions for one or both of the shipments, i.e., the shipment from thee-commerce retailer to the corresponding one of the local shippingaddresses, and the shipment from the corresponding one of the localshipping addresses to the corresponding one of the physical addresses inthe at least one country other than the first country.

The indication of the desired form of shipping from the e-commerceretailer to the corresponding one of the local shipping addresses, orthe indication of the desired form of shipping from the correspondingone of the local shipping addresses to the corresponding one of thephysical addresses in the at least one country other than the firstcountry, or both, as the case may be, is responsive to the shippingoption information.

In one or more embodiments, the shipping option information includes atleast one of cost and speed information for each of the at least twooptions.

Cross border shipping is currently an inconvenience to both the consumerand the merchant. From the consumer perspective, it involves having todeal with the merchant and cross border shipping service individually asthe two entities do not have a relationship with each other. From amerchant perspective, cross border shipping is prohibitively expensivewhen dealing with low volumes and far more complex than domesticshipping due to differing regulations, taxes, insurance cost, etc. Oneor more embodiments advantageously solve both the merchant and consumerproblem by integrating with a worldwide shipping provider andnegotiating affordable rates by aggregating the volumes of multiplemerchants. Merchants can log into their wallet accounts and select whichcountries their current logistics providers ship to and which countriesthey are willing to ship to. When a consumer is redirected to the walletfrom the merchant site, the wallet compares the consumer's shippingaddress with both lists to determine if a cross border shipping serviceis required. If such a service is required, the wallet retrieves theshipping options and rates from the cross border shipping service andpresents them to the consumer based on the rules preset by the merchant,or sends the rates to the merchant if no rules have been preset. Oncethe wallet receives confirmation from the merchant that the transactionwas successful, the wallet passes an invoice and instructions on how tofulfill the order (shipping labels, pickup times & locations etc.) fromthe logistics provider to the merchant.

One or more embodiments advantageously address one or more of thefollowing technical issues:

-   -   Creating a process flow where the wallet is the pass-through        between the merchant and logistics provider;    -   Creating the shipping functions in the merchant account that        allow merchants to select their preferences;    -   Creating the comparison function in the wallet transaction flow        that allows the wallet to compare the consumer's data with the        merchant's preferences.

Given the discussion thus far, it will be appreciated that, in generalterms, still another exemplary method includes the step 8108 ofobtaining, at an electronic wallet server 5497, product information inconnection with an on-line shopping session of a consumer 598 with ane-commerce retailer 1999. This step can be carried out, for example,using e-commerce retailer interface module 5473. A further step 8111includes dispatching, from the electronic wallet server, shipping optioninformation, destined for the consumer, providing at least two optionsfor shipping goods, associated with the product information, from thee-commerce retailer to the consumer. This step can be carried out, forexample, using e-commerce retailer interface module 5473 and shippingengine module 5995. An even further step 8112 includes obtaining, at theelectronic wallet server, in connection with the on-line shoppingsession, an indication of a desired form of shipping from the e-commerceretailer to the consumer. The indication is based on the shipping optioninformation. This step can be carried out, for example, using e-commerceretailer interface module 5473 and/or GUI 5477.

In some embodiments, a third party provides alternative shipping methodsbeyond what the merchant will make available. This includes theall-domestic case and the cross-border case. Where the merchantoutsources the shipping, some merchant integration may be appropriate. Achoice can be provided with respect to domestic shipping, either becausethe whole transaction is in one country, or as to the first (domestic)part of an international transaction. If choice is only from theshipping merchant 599 to the consumer, merchant integration withretailer 895 is typically not required. The third party can be ashipping merchant 5999, the operator of platform 5497 (e.g., theoperator of a payment network 2008), or the like.

Again, in one or more embodiments, the shipping option informationincludes at least one of cost and speed information for each of the atleast two options.

In some cases, an additional step includes providing a system, whereinthe system includes distinct software modules. Each of the distinctsoftware modules is embodied on a non-transitory computer-readablestorage medium. The distinct software modules include at least ane-commerce retailer interface module 5473 and a shipping engine module5995. The steps are then carried out or otherwise facilitated by themodules, as set forth above.

The wallet interface can pop-up at the merchant web site or the consumercan be redirected to the e-wallet site; therefore last step can beimplemented either by the interface module 5473 or GUI 5477.

One or more embodiments thus contemplate an apparatus, such as a serveron which electronic wallet platform 5497 runs, including a memory, andat least one processor, coupled to the memory, and operative to carryout any one, some, or all of the method steps just described. In one ormore embodiments, distinct software modules stored in a non-transitorystorage medium, when loaded in to the memory, configure the at least oneprocessor to be operative to carry out any one, some, or all of themethod steps just described. As noted, the modules can include ane-commerce retailer interface module 5473 and a shipping engine module5995, and optionally a GUI module 5477.

Furthermore with regard to domestic shipping for the merchant, considerthe following scenarios:

-   -   1. The merchant has yet to engage a logistics company (e.g., a        start-up merchant);    -   2. The merchant's logistics company provides limited coverage        domestically;    -   3. a logistics partner associated with the e-wallet, payment        network operator, or the like, provides value added service that        the merchant's logistics company does not.

When redirecting the consumers to wallet, in one or more embodiments,the merchants indicate if they provide domestic shipping and if thereare cities or states that they are currently unable to ship to. Alongwith this information, the merchant also provides the wallet with anestimate of the package dimensions and weight.

When the wallet receives a consumer from a merchant site withoutdomestic shipping, it calculates the rates for the different shippingoptions and presents them to the merchant. The merchant can then amendthe rate before passing same back to the wallet to be presented to theconsumer. Alternatively, the merchant can log into the merchant's walletaccount and set pricing rules such as having a standard rate for aparticular country or adding an x% surcharge on top of the logisticscompany's rate. Once the consumer has selected his or her preferredshipping option, he or she proceeds to pay for the merchant's goods &for the shipping cost. Once the wallet receives confirmation from themerchant that the transaction was successful, the wallet passes aninvoice and instructions on how to fulfill the order (shipping labels,pickup times & locations etc.) from the logistics provider to themerchant.

When the wallet receives a consumer from a merchant site with limiteddomestic shipping coverage, it will compare the consumer's shippingaddress with the merchant's list of areas not covered. If the merchantis unable to ship to the consumer's address, the same process isinitiated as in the case when the merchant does not have domesticshipping.

If a merchant already has complete domestic shipping but would like touse the wallet-based shipping due to lower prices or value addedservices such as insurance or pick up services, the merchant can selectunder which circumstances it would like to use the wallet shippingservice by logging into the merchant's account in the wallet. Examplesof such circumstances could be when the item to be shipped is fragile orwhen the value of the items exceeds a certain amount. With thesesettings integrated, the wallet will, in one or more embodiments,initiate domestic shipping when any of these conditions are met.

Merchants typically do not disseminate the weight and dimensions oftheir packages to other parties in the payment process. Large merchantshave their own inventory management system and small or medium sizedmerchants set their own shipping charges or check the rate with theshipping service. In order for merchants (especially small and mediumsized merchants) to send over volumetric data, they would have to comeup with their own internal system for estimating the volumetricdimensions of the packaging needed for the products that the consumerhas ordered. This is relatively straightforward when the products areidentical or very similar in dimensions such as an order of multiplet-shirts. However, when different types of products are involved such asa belt, shoes, jeans and t-shirt, estimating the volumetric dimensionsof the packaging accurately becomes far more challenging and is usuallyoverestimated.

One or more embodiments address this issue by providing such a systemfor the merchants.

Given the discussion thus far, and referring to FIG. 7, it will beappreciated that, in general terms, an even further exemplary methodincludes the step of obtaining, by an electronic wallet platform 597,transaction data pertaining to a transaction between a consumer 2002 anda merchant 1999 for provision of at least one of goods and services. Thetransaction data can include, for example, a PAN and/or other accountnumber and/or other identifying indicia of a cardholder; data pertainingto the merchant (e.g., merchant category code or MCC), amount of thetransaction, time and/or place of the transaction; where available,item-level data from a scanner 134, and so on. The electronic walletplatform has at least first and second funding sources available. Thisstep can be carried out, for example, using e-commerce retailerinterface module 5473. A further step includes dispatching, from theelectronic wallet platform 597, based on the transaction data, a firstcost scenario for the transaction based on use of the first one of thefunding sources and a second cost scenario for the transaction based onuse of the second one of the funding sources. The first and second costscenarios are destined for the consumer 2002. This step can be carriedout, for example, using an offer comparison module; a non-limitingexample thereof is that formed by elements 1997, 1998 in FIG. 7. An evenfurther step includes obtaining, at the electronic wallet platform 597,from the consumer 2002, a selection, from among the at least first andsecond funding sources, based on the first and second cost scenarios.This step can be carried out, for example, using e-commerce retailerinterface module 5473 and/or GUI 5477. A still further step includesproviding the merchant an account number associated with the selectedfunding source. This step can be carried out, for example, using API5999.

For example, one funding source might yield thirty frequent flierpoints; another might yield a 1% discount. This aspect can be serverbased or implemented via a smart phone application, for example. In thelatter case, a database (e.g., offers 5994 in memory 412) stores thediscount locally on the phone after the consumer opts-in to downloadingoffers to his or her phone—in some cases, all representative offers arestored in a central location such as registry 1997, displayed to theconsumer, and the consumer picks what he or she wants to locally storeon his or her smart phone or the like.

In some instances, the first and second cost scenarios are determinedbased on different promotions available with use of the at least firstand second funding sources (e.g., one card in the wallet offers apromotion and another doesn't; or they both offer promotions but thepromotions differ).

In some cases, at least one of the payment options includes a virtualcard number; the consumer selects the virtual card number; the merchantis provided with the virtual card number; and an authorization messagefor an amount of the transaction is sent to an issuer with an actualcard number not provided to the merchant. In such cases, one or moreembodiments determine at least a pertinent one of the first and secondcost scenarios based on the actual card number, advantageously allowingthe consumer to obtain a promotion or other benefit from the RCN whileonly divulging the VCN to the merchant. The notation “at least apertinent one of the first and second cost scenarios” accounts for thecase wherein one cost scenario is based on a VCN while another is basedon an RCN and so any pertinent offers would already be known, as well asthe case where both cost scenarios involve VCNs.

A point of sale (POS) device is typically designed to read only one cardat a time. Therefore, mobile wallets typically require the consumers toactivate the card they wish to use before presenting their mobile phonesto the POS. In order to compare discounts across cards, the POS firsthas to detect the inactive cards on the mobile wallet then pass on thediscounts for those inactive cards with the mobile wallet. Anothercurrent issue is the time taken to complete this process of comparinginactive cards. As an increasing number of cards are added to thewallet, the time taken for comparison increases. Since a transaction hasto be completed in a fixed amount of time, this restricts the number ofcards that can be compared within that timeframe. Finally, passing overthe data for all the discounts on the cards stored in a consumer'swallet is likely to be error prone as a lot of information is beingpassed.

In some cases, the cards being compared are cards of an identical brand,e.g., MasterCard cards. In some cases, the wallet addresses this issueby creating an offers database and having the offers for the cardsstored in the consumers' wallets downloaded onto their mobile phones, asseen at 5994; for example, whenever one of the consumers adds a card. Inat least some instances, periodic updating occurs, automatically ormanually, at the consumer's request. Of course, in alternativeembodiments, this information can be retrieved from an externaldatabase.

In some cases, in order for a merchant to detect what type of card isbeing used, the first 8 digits of the virtual card number typically needto be the same as the real card number. However, a virtual card numberis usually a randomly generated number thereby making the issuer of thecard unrecognizable to the merchant. In some cases, the wallet solvesthis problem through an offers database. Before passing the transactionto the issuer for authorization, the wallet compares the real cardnumber with the offers database and applies any applicable discounts.After the issuer authorizes the transaction, the wallet sends theupdated amount along with the details of the discount applied to theissuer.

In some cases, an additional step includes providing a system, whereinthe system includes distinct software modules. Each of the distinctsoftware modules is embodied on a non-transitory computer-readablestorage medium. The distinct software modules include at least ane-commerce retailer interface module 5473 and an offer comparison module(e.g. 1997, 1998), and an application program interface 5999. The stepsare then carried out or otherwise facilitated by the modules, as setforth above.

One or more embodiments thus contemplate an apparatus, such as a serveron which electronic wallet platform 5497 runs, including a memory, andat least one processor, coupled to the memory, and operative to carryout any one, some, or all of the method steps just described. In one ormore embodiments, distinct software modules stored in a non-transitorystorage medium, when loaded in to the memory, configure the at least oneprocessor to be operative to carry out any one, some, or all of themethod steps just described. As noted, the modules can include ane-commerce retailer interface module 5473 and an offer comparison module(e.g. 1997, 1998), and an application program interface 5999, andoptionally a GUI module 5477.

In yet another aspect, a method includes the step of obtaining, by anelectronic wallet mobile application 12, transaction data pertaining toa transaction between a consumer and a merchant for provision of atleast one of goods and services (non-limiting examples of transactiondata are provided above). The electronic wallet mobile application hasat least first and second funding sources available. A further stepincludes determining, by the electronic wallet mobile application, basedon the transaction data, a first cost scenario for the transaction basedon use of the first one of the funding sources and a second costscenario for the transaction based on use of the second one of thefunding sources (e.g., by comparing offers 5994 downloaded into memory412). A still further step includes obtaining, at the electronic walletmobile application, from the consumer, a selection, from among the atleast first and second funding sources, based on the first and secondcost scenarios (e.g., via interaction with screen 410). An even furtherstep includes providing the merchant an account number associated withthe selected funding source (e.g., via antenna 1800). In some instances,a further optional step includes downloading to the electronic walletmobile application at least first and second offers 5994. The first andsecond cost scenarios are based on the first and second offers.

“Cost scenarios” should be broadly understood to include direct totalcost comparison, the possibility of receiving a free gift in onescenario but not another; the possibility of different free gifts beingavailable in different scenarios, the possibility of coupons beingoffered in some scenarios but not others; the possibility of differentcoupons being offered in different scenarios, and so on.

From the perspective of one or more servers, steps include downloadingthe application, VCNs, and offers to the smart phone or the like, andintercepting an “auth” request with the VCN and converting same to theRCN.

One or more embodiments thus contemplate an apparatus, such as a mobilephone 10, including a memory, and at least one processor, coupled to thememory, and operative to carry out any one, some, or all of the methodsteps just described. In one or more embodiments, one or more distinctsoftware modules stored in a non-transitory storage medium, when loadedin to the memory, configure the at least one processor to be operativeto carry out any one, some, or all of the method steps just described.As noted, the modules can include wallet app 12.

As noted, one or more embodiments of the invention or elements thereofcan be implemented in the form of a system (or apparatus) including amemory and at least one processor that is coupled to the memory andoperative to perform or otherwise facilitate exemplary method steps.Examples include a server 300 or smart phone 10 or the like.

System and Article of Manufacture Details

Embodiments of the invention can employ hardware and/or hardware andsoftware aspects. Software includes but is not limited to firmware,resident software, microcode, etc. Software might be employed, forexample, in connection with one or more of a terminal 122, 124, 125,126; a reader 132; payment devices such as cards 102, 112; a host,server, and/or processing center 140, 142, 144 (optionally with datawarehouse 154) of a merchant, issuer, acquirer, processor, or operatorof a network 2008 operating according to a payment system standard(and/or specification), as well as smart phone 10, a wallet serverrunning wallet platform 597 or 5497, or other server(s). Firmware mightbe employed, for example, in connection with payment devices such ascards 102, 112 and reader 132. Firmware provides a number of basicfunctions (e.g., display, print, accept keystrokes) that in themselvesdo not provide the final end-use application, but rather are buildingblocks; software links the building blocks together to deliver a usablesolution.

FIG. 8 is a block diagram of a system 300 that can implement part or allof one or more aspects or processes of the invention. As shown in FIG.8, memory 330 configures the processor 320 (which could correspond,e.g., to processor portions 106, 116, 130; processors of remote hosts incenters 140, 142, 144; processors of servers implementing the walletplatform(s) or other blocks shown in the figures, and the like) toimplement one or more aspects of the methods, steps, and functionsdisclosed herein (collectively, shown as process 380 in FIG. 8).Different method steps can be performed by different processors. Thememory 330 could be distributed or local and the processor 320 could bedistributed or singular. The memory 330 could be implemented as anelectrical, magnetic or optical memory, or any combination of these orother types of storage devices (including memory portions as describedabove with respect to cards 102, 112); memory 412 of smart phone 10 maybe similar, for example). It should be noted that if distributedprocessors are employed, each distributed processor that makes upprocessor 320 generally contains its own addressable memory space. Itshould also be noted that some or all of computer system 300 can beincorporated into an application-specific or general-use integratedcircuit. For example, one or more method steps could be implemented inhardware in an ASIC rather than using firmware. Display 340 isrepresentative of a variety of possible input/output devices (e.g.,displays, mice, keyboards, and the like).

The notation “to/from network” is indicative of a variety of possiblenetwork interface devices.

As is known in the art, part or all of one or more aspects of themethods and apparatus discussed herein may be distributed as an articleof manufacture that itself comprises a tangible computer readablerecordable storage medium having computer readable code means embodiedthereon. The computer readable program code means is operable, inconjunction with a computer system, to carry out all or some of thesteps to perform the methods or create the apparatuses discussed herein.A computer-usable medium may, in general, be a recordable medium (e.g.,floppy disks, hard drives, compact disks, EEPROMs, or memory cards) ormay be a transmission medium (e.g., a network comprising fiber-optics,the world-wide web, cables, or a wireless channel using time-divisionmultiple access, code-division multiple access, or other radio-frequencychannel). Any medium known or developed that can store informationsuitable for use with a computer system may be used. Thecomputer-readable code means is any mechanism for allowing a computer toread instructions and data, such as magnetic variations on a magneticmedia or height variations on the surface of a compact disk. The mediumcan be distributed on multiple physical devices (or over multiplenetworks). For example, one device could be a physical memory mediaassociated with a terminal and another device could be a physical memorymedia associated with a processing center. As used herein, a tangiblecomputer-readable recordable storage medium is defined to encompass anon-transitory recordable medium, examples of which are set forth above,but does not encompass a transmission medium or disembodied signal.

The computer systems and servers described herein each contain a memorythat will configure associated processors to implement the methods,steps, and functions disclosed herein. Such methods, steps, andfunctions can be carried out, by way of example and not limitation, byprocessing capability on elements 140, 142, 144, 597, 5497 (i.e.,physical machine(s) on which e-wallet platform and its associatedinterface and/or database modules run), 2004, 2006, 2008, 2010;processor 402; or by any combination of the foregoing. The memoriescould be distributed or local and the processors could be distributed orsingular. The memories could be implemented as an electrical, magneticor optical memory, or any combination of these or other types of storagedevices. Moreover, the term “memory” should be construed broadly enoughto encompass any information able to be read from or written to anaddress in the addressable space accessed by an associated processor.With this definition, information on a network is still within a memorybecause the associated processor can retrieve the information from thenetwork.

Thus, elements of one or more embodiments of the invention can make useof computer technology with appropriate instructions to implement methodsteps described herein as being performed by one or more processors. Thevarious platforms can be implemented, for example, using one or moreservers which include a memory and at least one processor coupled to thememory. The memory could load appropriate software. The processor can beoperative to perform one or more method steps described herein orotherwise facilitate their performance.

Accordingly, it will be appreciated that one or more embodiments of theinvention can include a computer program comprising computer programcode means adapted to perform one or all of the steps of any methods orclaims set forth herein when such program is run on a computer, and thatsuch program may be embodied on a computer readable medium. Further, oneor more embodiments of the present invention can include a computercomprising code adapted to cause the computer to carry out one or moresteps of methods or claims set forth herein, together with one or moreapparatus elements or features as depicted and described herein.

As used herein, including the claims, a “server” includes a physicaldata processing system (for example, system 300 as shown in FIG. 8)running a server program. It will be understood that such a physicalserver may or may not include a display, keyboard, or other input/outputcomponents. A “host” includes a physical data processing system (forexample, system 300 as shown in FIG. 8) running an appropriate program.It will be understood that such a host may or may not include a display,keyboard, or other input/output components.

Furthermore, it should be noted that any of the methods described hereincan include an additional step of providing a system comprising distinctsoftware modules embodied on one or more tangible computer readablestorage media. All the modules (or any subset thereof) can be on thesame medium, or each can be on a different medium, for example. Themodules can include any or all of the components shown in the figures.In one or more embodiments, the modules include modules to implement thefunctional blocks shown in FIGS. 5 and/or 54; the application 12; and soon. The blocks may be implemented by the software modules together withcorresponding memories and one or more processors. The modules can run,for example on one or more hardware processors of one or more e-walletservers; in general, all could run on the same server, each could run ona separate server, and so on. Blocks 1479, 5479 in some instances, couldrun on one or more database servers. In a preferred but non-limitingapproach, element 597, 5497 includes a software platform while theinterface modules include code to carry out the indicated functionalityas well as any required translation functionality to interface with theexternal systems. The method steps can then be carried out using thedistinct software modules of the system, as described above, executingon the one or more hardware processors. Further, a computer programproduct can include a tangible computer-readable recordable storagemedium with code adapted to be executed to carry out one or more methodsteps described herein, including the provision of the system with thedistinct software modules.

Computers discussed herein can be interconnected, for example, by one ormore of network 138, 987, 2008, another virtual private network (VPN),the Internet, a local area and/or wide area network (LAN and/or WAN),via an EDI layer, and so on. The computers can be programmed, forexample, in compiled, interpreted, object-oriented, assembly, and/ormachine languages, for example, one or more of C, C++, Java, VisualBasic, JavaScript or other ECMAScript based scripting languages, and thelike (an exemplary and non-limiting list), and can also make use of, forexample, Extensible Markup Language (XML), JSON, name/value pairs, knownapplication programs such as relational database applications,spreadsheets, and the like. The computers can be programmed to implementthe logic depicted in the flow charts and other figures. At least somemessages, in at least some instances, can be in accordance with ISO8583.

Although illustrative embodiments of the present invention have beendescribed herein with reference to the accompanying drawings, it is tobe understood that the invention is not limited to those preciseembodiments, and that various other changes and modifications may bemade by one skilled in the art without departing from the scope orspirit of the invention.

What is claimed is:
 1. A method comprising the steps of: obtaining, atan electronic wallet platform, registration information for a pluralityof consumers; making available to said consumers a secure applicationfor portable devices of said consumers which affords said consumers anoption to select from multiple methods to pay for transactions withmerchants, said multiple methods being based, at least in part, on saidregistration information, at least one of said multiple methodscomprising a virtual card number; intercepting an authorization request,from a given one of said merchants, for an amount of a given one of saidtransactions to be charged against a given one of said virtual cardnumbers, said given one of said transactions comprising a given one ofsaid consumers presenting a given one of said portable devices, havingsaid secure application thereon, at a point-of-sale terminal of saidgiven one of said merchants, said virtual card number having beenprovided to said merchant via communication between said given one ofsaid portable devices and said point-of-sale terminal of said given oneof said merchants; translating said given one of said virtual cardnumbers into an actual card number which is not provided to said givenone of said merchants; and passing said authorization request to anissuer, with said actual card number therein.
 2. The method of claim 1,further comprising providing a system, wherein the system comprisesdistinct software modules, each of the distinct software modules beingembodied on a non-transitory computer-readable storage medium, andwherein the distinct software modules comprise a registration module, auser interface module, an application store module, and an accountnumber mapping engine module; wherein: said obtaining of saidregistration information is carried out by said registration module andsaid user interface module executing on at least one hardware processor;said making available of said secure application is carried out by saidapplication store module executing on said at least one hardwareprocessor; said intercepting of said authorization request, saidtranslating of said virtual card number, and said passing of saidauthorization request are carried out by executing said account numbermapping engine module on said at least one hardware processor.